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'