frame and message redisplay skipped if next input already present?

frame and message redisplay skipped if next input already present?

[Drew Adams]

I don't know if this is a bug or if I just don't know how to manage this
properly. I've searched the doc and source code, but I haven't found the
info I need.

Consider this function (this is a pared-down version but it still shows the
pb):

(defun bg ()
  (interactive)
  (let ((indx 0) evnt)
    (while (progn (setq evnt (read-event) indx (1+ indx))
                  (not (equal evnt 6))) ; C-f to stop
      (set-background-color (nth indx x-colors))
      (message "New bg: %s" (cdr (assq 'background-color
(frame-parameters)))))))

This just changes the background color with each key press (C-f stops the
loop). Again, this is not the real functionality I use, but it shows the
problem.

When I hold down a key continually, so that the loop repeats quickly, the
text in the frame is not redisplayed, and the message is not updated (a
previous message remains in the echo area).  By the frame not being
redisplayed, I mean that it appears temporarily empty, or at least partly
blank - the bottom portion is blank, as if the frame didn't have time to be
completely "painted" before the next loop cycle.

When I stop holding down the key, the frame text is updated correctly and
the latest message is shown in the echo area. IOW, while I hold down a key,
I see only the initial (or an intermediate, out-of-date) message and a
more-or-less blank frame (but the background color is updated properly and
immediately, it seems). When I stop, things appear normal again.

In a virgin emacs -q the problem doesn't really manifest itself very well,
but it seems to get worse as I load more of my code (e.g. more of the frame
appears blank when holding down a key).

I haven't been able to determine anything specific in my environment that
causes this. I'm guessing that there is not one single thing that causes it,
but rather that the frame & `message' display are just slowed down because
of various code I use, and that the already-available key input somehow
suppresses the display of `message' and the frame contents. IOW, I'm
guessing that `message' and the frame-contents update (but not the color
change) are _skipped_ - the available input being processed without them -
perhaps as some kind of display optimization.

Anyway, I'm wondering if someone has an idea what's going on and what I can
do about it. Is it "normal" that this would happen if display is slowed down
a bit and input is received quickly? If so, is there some way I can _force_
the `message' to appear and the frame contents to be displayed at each loop
go-round?

IOW, I would like the logic of the loop to be respected rigorously, without
any steps being skipped: 1) read event, 2) update frame color and redisplay
its contents, 3) write `message'. I would rather that the entire loop cycle
be slowed down than that any of the steps be skipped.

This behavior is very annoying - there is no ongoing feedback for each frame
change as there should be. I do not get this behavior in Emacs 20, BTW,
using the same code - there is no such problem there: the code just does
what it says.

Thanks for any insight on this.

 - Drew

In GNU Emacs 21.3.50.1 (i386-mingw-nt5.1.2600)
 of 2004-07-26 on BERATUNG4
configured using `configure --with-gcc
(3.3) --cflags -I../../jpeg-6b-1/include -I../../libpng-1.2.4-1/include -I..
/../tiff-3.5.7/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.1.4-1/in
clude'

Re: frame and message redisplay skipped if next input already present?

[Jan D.]

2005-01-16 kl. 08.09 skrev Drew Adams:

> I don't know if this i
> When I hold down a key continually, so that the loop repeats quickly, 
> the
> text in the frame is not redisplayed, and the message is not updated (a
> previous message remains in the echo area).  By the frame not being
> redisplayed, I mean that it appears temporarily empty, or at least 
> partly
> blank - the bottom portion is blank, as if the frame didn't have time 
> to be
> completely "painted" before the next loop cycle.

Set the variable redisplay-dont-pause to t.  It is nil by default.

	Jan D.

RE: frame and message redisplay skipped if next input alreadypresent?

[Drew Adams]

    Set the variable redisplay-dont-pause to t.  It is nil by default.

Wow! Thank you so much, Jan. I searched and searched for such a "key".
Apparently, I just blew right past it when I read the Display section of
Info _and_ when I searched through NEWS.

This is (one reason) why this list is so great. I wasn't sure if this should
be a question for help-gnu-emacs, a pb report for emacs-pretest, or a design
pb for emacs-devel. (It turns out it that it should have been a question for
help-gnu-emacs.)

 - Drew

Re: frame and message redisplay skipped if next input alreadypresent?

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 16 Jan 2005 08:08:28 -0800, "Drew Adams" <drew.adams@oracle.com> said:

>>     Set the variable redisplay-dont-pause to t.  It is nil by
>> default.
>  Wow! Thank you so much, Jan.

I think the echo area is supposed to be updated even if
redisplay-dont-pause is set to nil.  Currently x_flush in w32term.c is
empty, but maybe some flushing would be needed there.  Is there any
counterpart of XFlush in W32?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: frame and message redisplay skipped if next input alreadypresent?

[Lennart Borgman]

----- Original Message ----- 
From: "YAMAMOTO Mitsuharu" <mituharu@math.s.chiba-u.ac.jp>

> I think the echo area is supposed to be updated even if
> redisplay-dont-pause is set to nil.  Currently x_flush in w32term.c is
> empty, but maybe some flushing would be needed there.  Is there any
> counterpart of XFlush in W32?

Maybe something like UpdateWindow? And for better performance a
specification of the "Udate Region". MSDN has more info about this.