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

[Steven Allen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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).

No? E.g., if I have half a line (or half an image) visible and move my
point off that line, I wouldn't expect that line to suddenly scroll out
of view _unless_ the entire screen needs to scroll because the
text/image is larger than the entire screen.

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

I'm not sure how visual-line-mode and/or truncation might be affected, I
tried both and they seemed to work. All this patch does is restore the
vertical scroll position after moving point (`line-move' is, first and
foremost, a function to move point).

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

It sounds like vscroll may not have been intended to be used this way,
but (a) it's now used this way by a package shipped with Emacs and (b)
smooth pixel-scrolling is a feature expected of all modern GUIs. It
would be a pity to have a half-broken implementation.

The only options I can see for `pixel-scroll-precision-mode' are:

1. Advising `line-move' to restore the vertical scroll position.
2. Forcibly aligning the vertical scroll on touch end (which kind of
defeats the point of the mode).
3. Leaving things as-is and accepting that the window will scroll a bit
when the user calls a command that eventually calls `line-move'.

None of these options are acceptable, in my opinion.

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

See the comment above that function:

;; This is like line-move-1 except that it also performs
;; vertical scrolling of tall images if appropriate.
;; That is not really a clean thing to do, since it mixes
;; scrolling with cursor motion.  But so far we don't have
;; a cleaner solution to the problem of making C-n do something
;; useful given a tall image.

This function is very clearly about cursor motion, not scrolling, and
shouldn't mess with the current scroll position.