Re: Redisplay while evaluating Lisp code
Some time ago, Hrvoje Niksic wrote...
|+
| Do this simple test. Evaluate (while t), and while XEmacs is looping,
| minimize it and then maximize it. Under X, the frame is not redrawn,
| and this has been the case since as long as I've used XEmacs (19.12).
|
| However, under Windows this is handled correctly -- redisplay is
| invoked even when XEmacs is evaluating Lisp code. Just how did you
| guys do that?! :-)
When Fwhile calls QUITP, Windows event loop retrieves all accumulated
so far messages from Windows message queue. Some of these messages
cause XEmacs events to accumulate in internal queues of the event loop
implementation (there are two, as events prioritized on "system"
and "user" upon queueing). Among other messages, there is WM_PAINT, an
analogue of the Expose event. When dispatched, it causes redisplay not
through redisplay(), rather using redisplay_exposed_* ().
The message queue is drained to see if there are any C-g's typed.
The redisplay behavoir you mention appears to be a side effect of
this mechanism...
In X, different approch is used: C-g's are previewed right out
of the X queue. This way expose events are not dispatched, so
frame is not redraw until a call to Fnext_event ().
There is another consequence, and I do not know is it good or
bad. To see it, start Task Manager (C+Sh+ESC anywhere in Windows),
and click on the "Performance" tab. You will see CPU meter,
staying at 100% when (while t) is looping.
Now, press left button on the frame side or corner, as if you
are gonig to drag it. CPU drops down to 0. While you resize
the frame, real redisplay() is called, to update frame contents.
This means that rediplay may get called any time QUITP is executed.
More to this, resizing frame may cause frame windows to be deleted,
and all that could happen while a function in quit check.
Looks dangerous, doesn't it? (This can be fixed leaving
redisplay-in-eval bonus intact).
Kirill