GNU bug report logs - #72323
31.0.50; line-move unconditionally resets vscroll to 0

Previous Next

Full log

View this message in rfc822 format

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 28 Jul 2024 13:07:09 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: 72323 <at> debbugs.gnu.org, storm <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.