Re: Make scroll-{up, down} move point to {start, end} of newly visible text

[Eli Zaretskii <eliz@gnu.org>]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Thu, 10 Aug 2023 20:06:23 +0200
> 
> Eli Zaretskii wrote:
> 
> >>> I think your mental model of how scrolling works in Emacs
> >>> is not accurate. [...]
> >> 
> >> That can be helped,
> >> 
> >> (defun scroll-up-1 ()
> >>   (interactive)
> >>   (scroll-down 1) )
> >> 
> >> (defun scroll-down-1 ()
> >>   (interactive)
> >>   (scroll-up 1) )
> >
> > I asked what you thought happens in Emacs as part of the
> > call to scroll-down. If you think that function actually
> > scrolls the text in the window, then that's not what happens
> > in reality. The scrolling is performed as part of redisplay,
> > after scroll-up exits.
> 
> But it can still be controlled from Elisp. We would have
> another function around the scroll function, and that other
> function would be used instead. Normally it would just call
> the scroll function. Normally - but not always :)

We've lost context.  This sub-thread began when you said:

  If one can get the state of scrolling in a window in Elisp one
  could solve this in Elisp only since then one could write
  a new scroll function on top of the old, and what it would do
  is - based on that information - it would either scroll
  normally or not call the function at all, if scrolling was
  determined not to make any sense.

So now please explain what you mean by "the state of scrolling" and
how would you determine that "scrolling does not make any sense"?

My point is that "the state of scrolling" (at least my interpretation
of that) is only known when the scrolling was already done, by which
time it's too late to try to figure out whether "scrolling does not
make any sense".  That's because Lisp code doesn't compute how to
scroll the window, and thus doesn't know what would scrolling yield.
The actual scrolling is done by the display engine, in C code.