Re: [Jered Sandner] [Bug: 21.4.13] Infinite loop when trying to run font-lock-mode
Stephen J. Turnbull wrote:
Andy, could you take a look at this? I advised c.e.x that "the
widget
guy" is busy, but since people _will_ build with Motif :-( we oughtta
try to fix/work-around this.
Several people have reported similar problems, I believe they are all
recent Solaris builds.
Jered Sandner wrote:
On this build of XEmacs, I go into what appears to be an infinite
loop
when I try to enter font-lock-mode. I can reproduce it very easily.
1) xemacs -vanilla
2) M-x font-lock-mode
At this point, the fontification progress bar will come up at the bottom
of the XEmacs window with the thumb at the left and flash forever as it
tries to fontify "scratch". Pressing Ctrl-C several times will fontify
the buffer and return control to the user. The bigger the buffer being
fontified, the more times you have to press Ctrl-C to get it to finish.
(One can also click the "Stop" button repeatedly and accomplish the same
thing.)
I see it with openmotif-2.1.30-4 on RedHat 6.2.
I've tracked it down a bit further, and it basically boils down to the
fact that the code which handles an Expose event ends up generating
another Expose event.
From what I've seen so far, one likely candidate is the fact that
redisplay_clear_region() unmaps any subwindows in the region, which
will result in the area behind the subwindows being exposed.
The main evidence for this hypothesis is:
1. xmon shows continuous Unmap/Map requests for both of the clip
windows (the ones called "clip-window", created in
x_widget_instantiate()); one is for the progress gauge, the other for
the stop button.
2. gdb shows continuous calls to unmap_subwindow() via
redisplay_clear_region().
3. If you obscure the whole of either of the two clip windows, the
cycle is broken.
--
Glynn Clements <glynn.clements(a)virgin.net>