Re: redisplay-dont-pause

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 15 Sep 2011 18:02:52 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> 
>     When the value is nil, Emacs checks at several places during redisplay
>     whether some input is available, and if so, it aborts the redisplay
>     cycle to handle the incoming input.  That has the effect of forcing a
>     full redisplay on the next opportunity, for those frames that were not
>     completely redisplayed.  Here, "full" means that all display
>     optimizations are wholesale disabled for all windows on the frame.
> 
> That is strange.  I wonder why it does that?

Because the optimizations rely on the display being up to date, which
cannot be assured if redisplay was aborted half way through.  The
current display engine is very conservative about that, and any of the
indications that the display might not be entirely accurate disable
most if not all of the optimizations.

> In the old days, Emacs would update the display records for each line
> that it output, so that the subsequent redisplay would know where it
> was starting from.

There are no such fine-grained display records in the current display
engine, AFAIK.  Perhaps that's something that was planned, but never
implemented.  Or maybe implementing it is very hard with the current
display features, I really cannot say.

> Over any substantial period, if the commands come so fast that excuting
> them leaves no time for redisplay, Emacs should not redisplay at all.
> You might describe that by saying "the display gets stuck", but this
> is what should happen.

Right.  But the net effect on the user experience is negative.

>      . it effectively slows down the keyboard auto-repeat rate (because
>        events need to wait for the end of redisplay before they are
>        processed), but only by a small factor, so the user experience is
>        that Emacs does succeed to keep up.
> 
> I am lost here.  The keyboard determines its auto-repeat rate.
> Emacs can't slow it down.  All it can do is skip redisplays so
> as to cope with the commands at the rate they are generated.

That's why I said "effectively".  The keyboard of course works at its
nominal speed, but Emacs lets input events wait in its queue for some
short time, thus the rate of event processing is slightly lower than
what the keyboard produces.  It's hard to time such fast sequences
with the existing facilities, but I'm quite sure that letting
redisplay optimizations do their best is on balance a win, and only
some input events need to wait in the queue before they are processed.
IOW, setting this variable non-nil actually helps Emacs to keep up
with high-rate input, because the cost of a full redisplay is so much
higher.