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

[Eli Zaretskii <eliz@gnu.org>]

> From: Steven Allen <steven@stebalien.com>
> Cc: luangruo@yahoo.com, 72323@debbugs.gnu.org, storm@cua.dk
> Date: Sun, 18 Aug 2024 10:38:29 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> Let's be precise about "move to another line":
> 
> - When window-start changes, vscroll becomes invalid because the lines at
>   the top of the screen (to which vscroll applies) has changed. I agree
>   that it must be reset in this case.
> - When point is moved up and down in such a way that window-start isn't
>   changed, vscroll is still perfectly valid as the top line in the
>   window hasn't changed.

I disagree.  When point moves to another screen line without moving
window-start, vscroll may or may not be valid.  Whether it is depends
on the details of what is on display.

>  vscroll is relative to the top line, not point.

No, vscroll is global for the entire window.  It affects the Y
coordinate of every screen line, not just that of the first screen
line.

> > 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.
> 
> Honestly, scrolling between lines is working perfectly.

It's a kludge that is very fragile, and sometimes breaks.