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

[Eli Zaretskii <eliz@gnu.org>]

> From: Steven Allen <steven@stebalien.com>
> Cc: 72323@debbugs.gnu.org, storm@cua.dk
> Date: Sun, 28 Jul 2024 13:07:09 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.

It depends on the details of the line from which you move cursor and
the one into which you move.  For example, if the former takes up
almost the entire window, then moving into the next one could cause
that next line to be only partially visible, and that is unacceptable
for the Emacs redisplay.

Once again: the vscroll value is pertinent only for the screen line
for which it was computed, because the way it is computed uses the
metrics of that line.  Once you move to another line, the value is no
longer pertinent.

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

They are relevant because the workhorse of vertical cursor movement is
vertical-motion, which needs special handling for each of these (and
other) use cases.  The fundamental reason is that each of these
features affects the layout of physical lines differently.

> I tried both and they seemed to work.

I believe you.  But I have too much gray hair from changes there that
then cause subtle problems in rare enough cases.

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

Emacs supports smooth scrolling only within a single screen line, and
that uses vscroll.  That's the original design intent of vscroll.
Smooth scrolling between lines is not really supported.
pixel-scrolling attempts to solve that, and does it well, but it does
have some problematic corners.  Those corners need to be solved inside
pixel-scroll code.

> 1. Advising `line-move' to restore the vertical scroll position.

That's not necessary.  If someone can come up with a version of
line-move that is specific to pixel-scroll, we can always call it
instead of line-move when pixel-scroll is in effect.

> 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 don't understand the latter two alternatives, but the first one
should show a way of fixing these issues without affecting all the
users 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.
> 
> 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.

Po Lu will tell, but my understanding of the comment is that it does
what it does out of necessity.