Re: redisplay-dont-pause is not mentioned in the Emacs manual

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> Date: Tue, 6 Jun 2006 12:40:16 -0700
> 
> I don't have a problem with the behavior. I was just explaining my
> misunderstanding of it

I didn't think you had a problem, I was trying to help you understand
how it works and why.

> "Processing user input takes absolute priority over redisplay.  If you
> call these functions when input is available, they do nothing
> immediately, but a full redisplay does happen eventually--after all the
> input has been processed." (node Refresh Screen)
> 
> "Emacs redisplays only when it pauses." (node Edebug Display Update)
> 
> "performs redisplay (provided there is no pending input from the user)"
> (node Waiting)
> 
> "`(sit-for 0)' is a convenient way to request a redisplay, without any
> delay." (node Waiting)
> 
> "Force redisplay of the current buffer's mode line and header line. The next
> redisplay will update..." (node Mode Line Basics)
> 
> "if you move point, do not expect the window-start position to change in
> response until after the next redisplay." (node Window Start)

I don't see any inaccuracies or unclear statements in these excerpts.
Perhaps I know too much ;-)  Feel free to point out in more words
which ones are confusing, and why.

> None of these contradicts what Kim wrote, but they don't come right out and
> say that redisplay happens immediately after input either.

Well, this one does, at least:

  a full redisplay does happen eventually--after all the input has
  been processed." (node Refresh Screen)

> They suggested to me that redisplay happens only occasionally, perhaps when
> Emacs can be certain that it's needed or via some timer. They also suggested
> to me that user input inhibits redisplay, so that it would occur only
> sometime later, when Emacs "pauses". I didn't understand that redisplay
> would occur _as soon as_ user input stopped.
> 
> IOW, to take the first quotation, it would have been clearer (to me), to say
> "immediately" after the input has been processed. "Eventually" "after" I
> understood; immediately after I did not understand until I read Kim's email.

Perhaps what is missing is the understanding of the structure of the
Emacs top-level code's flow control.  The following is a
simplified (perhaps greatly simplified) description.

The top level is basically an idle loop, where Emacs sits waiting for
user input.  Whenever some input comes in, it is processed, and Emacs
then returns to the idle loop.

That idle loop is where redisplay happens.  (Timers also fire there,
btw.)  That is, redisplay is entered only when Emacs is idle.  This is
why redisplay normally doesn't happen if Emacs is busy processing
something, and this is why redisplay will happen immediately when
Emacs becomes idle (a.k.a. ``pauses''), unless new input arrives in
the short window of opportunity between start of idleness and the call
to redisplay.

Maybe we should add something like this (sans any blatant inaccuracies
I might have let in) to the "Command Loop" node.