Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3

[Dmitry Gutov]

On 17.04.2020 20:35, Eli Zaretskii wrote:
> > Cc:address@hidden,address@hidden,address@hidden,address@hidden,
> >   address@hidden
> > From: Dmitry Gutov<address@hidden>
> > Date: Fri, 17 Apr 2020 20:04:04 +0300
> >
> > 1. (setq scroll-conservatively 1)
> >
> > 2. Visit xdisp.c.
> >
> > 3. Lean on C-n.
> >
> > 4. From time to time, you will see point jump into the middle of the
> > screen, when font-lock takes too long, apparently (or maybe it
> > corresponds to GC pauses).
> >
> > This shouldn't happen because next-line only moves by one line.
> And it doesn't.

What doesn't? It clearly does happen. And 'next-line' only moves by one 
line (the docstring says so, at least).

> What happens is that Emacs is sometimes unable to
> keep up with input, so when it comes to displaying the next screenful,
> point is already more than 1 line below the window's end.  So Emacs
> recenters.

I know. But these are internal details, which shouldn't affect the 
observable behavior this much.

And I'm not convinced that, if redisplay didn't happen, Emacs can't 
decide that scrolling happened anyway. After all, if that was the case, 
then in the original problem scenario (floor C-v, see Emacs freeze after 
a while), after Emacs unfreezes, the window start would have been the 
same (or almost the same) as when Emacs stopped updating the screen.

> That's why the special value of 101 was introduced: so that this
> recentering never happens.

This bug basically makes lower values (which I personally would 
otherwise choose to use, probably even the value of 1) frustratingly 
unreliable. That's both bad and non-obvious. Emacs clearly doesn't honor 
scroll-conservatively's description.