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

[Dmitry Gutov]

On 17.04.2020 21:48, Eli Zaretskii wrote:

> > > > 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 doesn't happen when next-line only moves by one line, then stops
> (as opposed to continue moving by one more line).

But next-line only moves by one line. It's the other invocations of it 
that perform subsequent movements. The fact that Emacs sometimes chooses 
to "merge" several invocations into one is a speed optimization. One 
that's not obvious to the casual user. And even many advanced ones, I'm 
fairly sure.

> > > 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.
>
> The display engine has no idea what happened or why.  All it knows is
> that point is more than one line below the window-bottom.  That's the
> basics of the MVC design of Emacs: redisplay is uncoupled from the
> changes made by the commands.

It seems that scrolling is rather coupled to redisplay, however. Which 
is something I've never been aware of in the many years of using Emacs.

There are different directions in which that could be changed, but maybe 
this one could be improved without changing the architecture.

> That said, if you can find a way of avoiding that, by all means
> propose a patch, I'm sure many users will be happier.

The current implementation is too rich for my blood (starting with no 
documentation for try_scrolling's arguments). But here's the idea:

At the beginning of each command, we can save the value of point. If, at 
the end, we're still in the same buffer, and the new value of point 
fails the scroll-conservatively check, count the lines between the 
previous value of point and the new one. If that number is <= 
scroll-conservatively, then scroll "conservatively" anyway.