bug#6671: moving point and scroll-conservatively

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 6671@debbugs.gnu.org
> Date: Thu, 24 Mar 2011 22:09:28 -0400
> 
> I don't think the problem is keyboard-triggered commands changing the
> buffer too fast between redisplays.  I've done a bit of tracing, and
> redisplay is called once for every one, some times two, calls to
> command-execute.  Certainly not the ten or twenty times that would cause
> window scrolling to fall behind.

It could easily fall behind with high enough rate of keyboard
auto-repeat operation.  There are 2 possible situations: when
redisplay-dont-pause is set and when it is nil.

When redisplay-dont-pause is set, we don't check for available input
until we finish one redisplay cycle completely.  When the user leans
on a key and high-rate auto-repeat is at work and, we can easily have
many keystrokes in the buffer by the time we finish a full redisplay,
especially if you have many large frames.  Processing many <down>
strokes, for example, can easily get you several screenfuls away.

When redisplay-dont-pause is nil, we check for input in several places
during redisplay, and bail out if there's input.  In that case, with
high-rate keyboard input, we quickly create a situation where
important data structures and flags are out of sync and cannot be
relied upon, and try_scrolling cannot be used at all, which again
means recentering (because we only try not to recenter inside
try_scrolling).

> Instead, the recentering is caused by the situation I described in an
> earlier email, where the action of fontification functions causes
> redisplay to become confused.  I don't know whether there are other
> causes of anomalous recentering, but that is the only one I have
> encountered while experimenting with the code.

Try leaning on <down> in etc/HELLO, after turning off font-lock.