March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Olivier Galibert

On Fri, Mar 17, 2000 at 05:33:32PM +0000, Andy Piper wrote: > This nukes some of the progress glitches people are seeing. This does not fix the "gauge in the wrong frame" problem. Actually, the grey background with the "fontifying" message appears in the right frame but without the gauge+stop widget in it, and the gauche+stop appears in the wrong frame. It dissapears only when I move another window on top of it (retrace event, I suppose). Nor the vc-hooks problem. Good luck. OG.

1 participants
0 comments

Re: modules anyone? 25 years, 1 month

Marat Boshernitsan

Martin Buchholz <martin(a)xemacs.org> writes: > >> The idea was that future code in a module could define a new lrecord > >> type dynamically, and increment last_lrecord_type_assigned. So it > >> actually makes sense for last_lrecord_type_assigned to be initialized > >> to lrecord_type_count and never subsequently modified in any code > >> shipped with XEmacs, and for various bits of code to use > >> last_lrecord_type_assigned instead of lrecord_type_count. Of course, > >> it doesn't make sense for modules to be loaded before being dumped, so > >> the dumper could use either symbol. However, it seems cleaner to use > >> last_lrecord_type_assigned. I suggest you resurrect > >> last_lrecord_type_assigned. > > OG> ...it for now simply doesn't work. You can't use > OG> DECLARE_LRECORD*/INIT_LRECORD* in a module to define a new type since > OG> you (rigthfully) killed the dynamicity in type number allocation. I > OG> didn't want to leave something that not so obviously didn't work. I > OG> don't want modules to know about last_lrecord_type_assigned or the > OG> lrecord_implementation array. > > It's true that DECLARE_LRECORD*/INIT_LRECORD* would have to have > dynamic versions manipulating last_lrecord_type_assigned (like the old > code) to be used in a module. Such macros are not written yet, > although writing them would be relatively straightforward. And the > need may never arise - the existing lisp object types are sufficient > for implementing any real-world functionality. I beg to differ. I use XEmacs modules in my application and I find myself needing to declare new object types quite often. Marat.

2 participants
1 comments

Re: Pixel-based scrolling mystery 25 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > "Wow," says I, "we have pixel-based scrolling, and I wasn't even aware > > of it." But no matter how hard I try, I cannot get it to work. > > Dragging the scrollbar scrolls by lines. > > It works for me (but not when dragging).. Try using the buttons on > your scrollbar that allow you to step line by line. Indeed, that works, although it's a bit buggy at the top/bottom edges. Now, why doesn't dragging work? I'm sure that's what most people mean when they refer to pixel-based scrolling. Having scrollbar *buttons* scroll pixel by pixel is pretty useless.

2 participants
1 comments

Pixel-based scrolling mystery 25 years, 1 month

Hrvoje Niksic

We have a NEWS entry that says: ** Pixel-based scrolling has been implemented. By default this will attempt to scroll in increments equal to the height of the default face. Set `window-pixel-scroll-increment' to modify this behaviour. "Wow," says I, "we have pixel-based scrolling, and I wasn't even aware of it." But no matter how hard I try, I cannot get it to work. Dragging the scrollbar scrolls by lines. Changing the value of window-pixel-scroll-increment doesn't seem to help. Its documentation says: `window-pixel-scroll-increment' is a simple built-in variable. Value: t Documentation: *Number of pixels to scroll by per requested line. If nil then normal line scrolling occurs regardless of line height. If t then scrolling is done in increments equal to the height of the default face. I'd expect that setting window-pixel-scroll-increment to 1 effectively enables pixel-based scrolling. Why doesn't it? How is one to interpret the above NEWS entry?

2 participants
1 comments

Re: crash when using W3 25 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > #7 0x8122e65 in signal_after_change (buf=0x857e6b8, start=0, orig_end=1, > new_end=0) at /scratch/vroonhof/xemacs/src/insdel.c:2291 I don't understand how start ends up being 0, short of a memory corruption. > P.S. Shouldn't bufcons and buffer be gcproed? I don't think so. bufcons maps over the list of indirect children, which is GC-safe.

1 participants
0 comments

Re: crash when using W3 25 years, 1 month

Jan Vroonhof

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > This is from a > > uname -a: Linux urysohn 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown > > ../configure '--debug=no' '--error-checking=none' '--with-athena=3d' Here is one from '../configure --cflags="-g -O2" #3 0x80aac73 in assert_failed ( file=0x81ec1e0 "/scratch/vroonhof/xemacs/src/insdel.c", line=1116, expr=0x81ebab6 "BUFFER_LIVE_P (buf)") at /scratch/vroonhof/xemacs/src/emacs.c:2753 #4 0x8121227 in bufpos_to_bytind (buf=0x857e6b8, x=0) at /scratch/vroonhof/xemacs/src/insdel.c:1116 #5 0x80e27af in map_extents (from=0, to=0, fn=0x80e6df8 <report_extent_modification_mapper>, arg=0xbfffec1c, obj=139978424, after=0x0, flags=15360) at /scratch/vroonhof/xemacs/src/extents.c:2283 #6 0x80e7046 in report_extent_modification (buffer=139978424, start=0, end=0, afterp=1) at /scratch/vroonhof/xemacs/src/extents.c:4700 #7 0x8122e65 in signal_after_change (buf=0x857e6b8, start=0, orig_end=1, new_end=0) at /scratch/vroonhof/xemacs/src/insdel.c:2291 #8 0x812391d in buffer_insert_string_1 (buf=0x857e6b8, pos=1, nonreloc=0xbfffed40 "HTTP/1.1 200 OK\r\nDate: Fri, 17 Mar 2000 14:21:41 GMT\r\nServer: Apache/1.3.3 (Unix) mod_perl/1.16\r\nLast-Modified: Fri, 17 Dec 1999 14:10:50 GMT\r\nETag: \"1f26-915-385a446a\"\r\nAccept-Ranges: bytes\r\nContent-"..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2564 (gdb) up #7 0x8122e65 in signal_after_change (buf=0x857e6b8, start=0, orig_end=1, new_end=0) at /scratch/vroonhof/xemacs/src/insdel.c:2291 2291 report_extent_modification (buffer, start, new_end, 1); (gdb) up #8 0x812391d in buffer_insert_string_1 (buf=0x857e6b8, pos=1, nonreloc=0xbfffed40 "HTTP/1.1 200 OK\r\nDate: Fri, 17 Mar 2000 14:21:41 GMT\r\nServer: Apache/1.3.3 (Unix) mod_perl/1.16\r\nLast-Modified: Fri, 17 Dec 1999 14:10:50 GMT\r\nETag: \"1f26-915-385a446a\"\r\nAccept-Ranges: bytes\r\nContent-"..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2564 2564 signal_after_change (buf, pos, pos, pos + cclen); As you said note the funny things going on with the variables.. Jan P.S. Shouldn't bufcons and buffer be gcproed?

1 participants
0 comments

Re: Aborting the progress gauge 25 years, 1 month

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > At 09:15 AM 3/17/00 +0100, Hrvoje Niksic wrote: > >What I mean is: when you issue (message "foo"), the message sticks > >around only until you press a key, or do anything that might require > >the echo area space. The same should happen with the progress gauge. > > > >I haven't looked at the code that places the gauge in the echo area, > >so I'm not sure how to implement it, yet. > > I'll use pre-idle-hook maybe. I though sit-for should quit if there > was input. sit-for does quit if there was input, but user is not aware of that. What he perceives is a gratuitous delay.

1 participants
0 comments

Re: Progress gauges! 25 years, 1 month

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > >Ah, the obligatory screenshot depicting the problem: > > I think the problem is your background pixmap - although why the > gutter is inheriting it but the modeline is not I don't know. For one, I don't want it to inherit. :-) I prefer the gray-bg modeline. In fact, it doesn't inherit because it has a background color (gray) specified, and it takes precedence over the background pixmap. This is a feature. There is also a bug, though: if a face inherits both a background pixmap and a background color, the above feature doesn't work; inherited background pixmap takes precedence over inherited background color, even if they come from the same depth of inheritance chain. For this reason, my .emacs has this: (set-face-background-pixmap 'modeline-mousable [nothing]) (set-face-background-pixmap 'modeline-buffer-id [nothing]) However, the question I ask myself is why the lettering on my dark background progress-gauge-thing is black. I'd want them to be white, as it's the case with the buffer tabs. > a) The gutter should use widget-face not gui-element-face > b) widget-face should not inherit the background pixmap. I can't argue for one or the other, as I don't understand the difference between the two faces, or the issues involved.

2 participants
1 comments

Re: NEWS update 2000-03-17 25 years, 1 month

Olivier Galibert

On Fri, Mar 17, 2000 at 03:41:09PM +0100, Hrvoje Niksic wrote: > This is all very experimental, though. Configure with `--pdump' to > -try testing it. NOTE: it is expected that `make' will fail after > -dumping `xemacs.dmp'. This is because Makefiles have not yet been > -modified to not expect `temacs' producing an `xemacs' executable. You > -can try it out by simply running `src/temacs'. If it starts without > -failure, the portable dumping worked. > - > -#### NOTE: the portable dumper is not really usable yet, because the > -state of built-in variables is not yet saved. Olivier promised to fix > -it. Nag, nag. > +try testing it. NOTE: the Makefile hackery needed to support portable > +dumping might be unfinished at the time of writing this. If `make' > +fails after writing `xemacs.dmp', you can still try running `temacs'. > +The failure can be due to Makefiles bogusly expecting `temacs' to > +produce an `xemacs' executable. #### Has this been fixed? It has. The Makefile hackery is finished (for unix, at least, I'd be surprised that --pdump even compiles on windows) for one particular definition of finished. I.e., I currently disagree with Martin on the naming of the dump file (or on whether there should be a dump file in the first place actually) so it is probably going to change again in the future, but right now there shouldn't be any more failures. Incidentally, if --pdump, there is no temacs executable produced anymore. OG.

1 participants
0 comments

Re: Aborting the progress gauge 25 years, 1 month

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > At 03:28 PM 3/16/00 +0100, Hrvoje Niksic wrote: > >I think the echo area progress gauge should behave like an echo area > >message -- removed at the first possible opportunity. > > Lead me - I wasn't sure how to do this effectively. What I mean is: when you issue (message "foo"), the message sticks around only until you press a key, or do anything that might require the echo area space. The same should happen with the progress gauge. I haven't looked at the code that places the gauge in the echo area, so I'm not sure how to implement it, yet.

2 participants
1 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta March 2000