bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0

[Eli Zaretskii]

> From: Steven Allen <steven@stebalien.com>
> Cc: 72323@debbugs.gnu.org, storm@cua.dk
> Date: Sat, 27 Jul 2024 13:10:03 -0700
> 
> >> Fixing home/end (beginning of line, end of line) case seems trivial:
> >> don't call `line-move' in these cases (or have `line-move' short-circuit
> >> when `arg' is 0). However, even after reading all the comments about
> >> scrolling images, I'm still not sure why it's necessary to reset vscroll
> >> to 0.
> >
> > Because otherwise what line-move does cannot be described in sensible
> > terms.  If vscroll is not reset, then what would be the reference for
> > such a "line move"?  By its very definition, line-move moves N screen
> > lines wrt the line which was its starting point, but with vscroll
> > non-zero that starting point could be anywhere.
> 
> I'm a bit confused because vscroll is about scrolling the window and
> `line-move' is about moving point (only incidentally scrolling the
> window if the point leaves it). Clearly `set-window-start' needs to
> reset `vscroll', but I'm not sure I understand why `line-move' does.

vscroll is not just about scrolling the window.  It is basically a
vertical offset from the screen line that shows window-start to the
top-most pixel shown in the window.  It is meant to enable to see the
tall screen line at window-start in its entirety.  Once point moves
off that screen line, vscroll is no longer pertinent, since the
important line, for which vscroll has been determined, has changed.
For example, imagine that the line into which point moves cannot be
displayed in its entirety with this vscroll, because it starts at a
different vertical coordinate (so its lower part could be below the
window bottom).

> Is this about detecting the correct column?

No, I don't think columns are related.

> > line-move is not just for scrolling across images, it is also about
> > scrolling across tall text lines and other display elements.  In any
> > case, asking for removal of that reset is a non-starter, for the
> > reasons explained above, so it isn't going to happen.  The solution
> > for any Lisp program that doesn't want vscroll to be rest is not to
> > call line-move.
> 
> Now that I do more testing, I can see how removing that line breaks
> `line-move' although I'm still not sure why.
> 
> Would it be acceptable to restore the vertical scroll position as long
> as `line-move' hasn't otherwise scrolled the screen? See attached patch.

Sorry, I don't want to make changes in that function whose purpose is
to serve use cases which this function is not designed to support.
The code there is quite fragile and it needs to support a large number
of use cases, some of which with subtle aspects (e.g., did you try
line truncation? did you try visual-line-mode? etc.).  In addition,
the code there is too tightly-coupled with code in the related
functions: line-move-1, line-move-partial, and line-move-finish.  They
all work in unison to support the various use cases, and changing one
without the others is very risky.  It took us a long time to arrive at
what we have there, solving quite a few bugs as we went.  Making
significant changes that at this point in support of application-level
issues would be unimaginable from where I stand.

Problems with pixel-scroll-precision-mode should be solved in that
mode.  I'm against modifying line-move and related subroutines in
order to solve problems in Lisp programs that are not bugs in the
algorithm of line-move.

I've added Po Lu to this discussion in the hope that he could have
comments and suggestions for solving the problems in
pixel-scroll-precision-mode you mentioned in the original message.