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

[Dmitry Gutov]

On 19.04.2020 22:06, Eli Zaretskii wrote:

> > > 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.
>
> It's not a "merge" and not an optimization, it's how Emacs was
> designed.  It only enters redisplay when it's idle.  If you invoke
> commands one after another quickly enough, more than one command will
> be executed before the next redisplay cycle.

The fact that Emacs's behavior can depend on when redisplay happens, and 
the user cannot reliably control it, is problematic IMHO.

> > 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.
>
> And if not, then what?

Then give up and move point to the middle of the window.

> Anyway, scrolling commands don't normally move point, they move the
> window-start.  Point then moves because redisplay brings it into
> view.  So I don't think your algorithm will work, at least not in the
> usual case.

I'm a lot less worried about scrolling "conservatively" when the user 
actually invokes the scrolling commands. In those scenarios, it's fairly 
natural to expect that point moves however Emacs prefers (but we also 
have scroll-preserve-screen-position).

Stefan's idea might improve on scrolling commands' behavior as well in 
this regard, but it could be slightly harder to implement.

> What you describe might be relevant to "scrolling" that happens if you
> lean on C-n, not on C-v.

C-n, or C-M-e, or C-s. These are indeed scenarios when the current 
behavior can be most surprising. The new users tend to lean on C-n and 
C-p a lot at first, I think, and that's when it bites the most. But even 
now I lean on C-n from time to time when speed-reading code.