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 11:40:42 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> Can you give me an example example where moving point invalidates
> vscroll (except when point would move partially or fully off screen)?

Why isn't the one example I gave enough?

The code in question doesn't know whether this is or isn't the case,
at least not in all cases and not without a lot of tedious layout
calculations.  Whether the current line will be fully visible is only
known after the window is redisplayed.  At which time we also check
that we didn't enter the scroll margins and other conditions that
require to scroll the window.  Keeping the vscroll would make all this
much more complicated, so we play it safe.