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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sun, 19 Apr 2020 20:09:04 +0300
> 
> > 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 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.

Not sure what you mean by "coupled" here.  As I explained, scrolling
is _implemented_ in redisplay.  The scrolling commands just calculate
where the window-start should be, they don't scroll anything.

> Which is something I've never been aware of in the many years of
> using Emacs.

With Emacs, one learns something new every day.  That includes
myself, of course.

> 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?

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.

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