Re: The unwarranted scrolling assumption

[Eli Zaretskii]

> Date: Mon, 21 Jun 2010 23:06:26 +0100
> From: David De La Harpe Golden <address@hidden>
> CC: address@hidden
> 
> font-lock-mode on:
> 
> redisplay-dont-pause nil (that's nil):
> 
> I counted about 114 visible recenters on one complete scrollthrough 
> (N.B. definitely recenters i.e. cursor restarting from the middle, not 
> just update lags),
> 
> redisplay-dont-pause t (that's t):
> 
> No visible recenters on one complete scrollthough.

After looking at the code and experimenting a bit, I think there's no
other way to prevent recentering on slow machines except set
redisplay-dont-pause non-nil.  (You could also try playing with
redisplay-preemption-period, which basically gives you more fine
granularity than just the ON/OFF you get with redisplay-dont-pause.)

I could perhaps make things a bit better by marking each frame's
windows, or even each window up to date as soon as it is redisplayed.
(By contrast, the current code only does that after _all_ frames were
completely redisplayed without being preempted by input that arrived.)
But that would hardly help in this simple use-case, where there's a
single frame and a single window on that frame.

> redisplay-dont-pause nil (that's nil):
> 
> Only visibly once in 20 whole buffer scrollthroughs (HELLO being a lot 
> shorter than window.c...), though with at least one of those update lags 
> every time.
> 
> redisplay-dont-pause t (that's t):
> 
> 11 times in 20 whole buffer scrollthroughs.

This is due to some other problem.  Do you really see Emacs
recentering the window with HELLO?  What I see is that the current
line is not recentered, but scrolled all the way to the top of the
window.  IOW, the cursor jumps to the first screen line, and then
moves down until it hits the end of the window.  Could it be that you
see this, instead of recentering?