bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view

bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view

[Dima Kogan]

Hi. This is an old bug; I've been observing it for years. I have
C-M-arrowkeys bound to scrolling commands:

  (global-set-key [C-M-down]  (lambda () (interactive) (let ((scroll-preserve-screen-position nil)) (scroll-up    3))))
  (global-set-key [C-M-up]    (lambda () (interactive) (let ((scroll-preserve-screen-position nil)) (scroll-up   -3))))
  (global-set-key [C-M-left]  (lambda () (interactive) (let ((scroll-preserve-screen-position nil)) (scroll-left -3))))
  (global-set-key [C-M-right] (lambda () (interactive) (let ((scroll-preserve-screen-position nil)) (scroll-left  3))))

The vertical scrolling works as expected: if the point is scrolled off
screen, the point moves to stay in-bounds.

I expect the same from horizontal scrolling, but it doesn't work.
Recipe:

1. emacs -Q --eval '(global-set-key [C-M-right]  (lambda () (interactive) (let ((scroll-preserve-screen-position t)) (scroll-left 3))))'

   Emacs comes up with the default text in the *scratch* buffer

2. (goto-char (point-min))

   Move the point to the beginning of the buffer. (point) evaluates to 1

3. C-M-right

   We scroll to the right. The point was on the left edge of the screen
   at position 1, which is now out of view. Emacs still draws the point
   at the left edge of the screen, implying that the point was moved to
   stay in-bounds. But this is not where the point actually is: (point)
   still evaluates to 1. I expect (point) to be updated with the new
   position

4. C-a

   Now, some commands behave strangely. For instance C-a should move to
   the start of the line. This is now off-screen, so I would expect
   emacs to scroll back so that we can see the beginning of the line.
   But emacs does nothing: the point was at position 1, and it was moved
   to position 1, so it doesn't see the need to scroll anything.

Thanks!

bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view

[Eli Zaretskii]

tags 50234 wishlist
thanks

> From: Dima Kogan <dima@secretsauce.net>
> Date: Sat, 28 Aug 2021 00:40:57 -0700
> 
> Hi. This is an old bug; I've been observing it for years.

It isn't a bug, it might be a missing feature.  Horizontal scroll
commands were never coded to support scroll-preserve-screen-position.
Only the vertical scroll commands support it.

The documentation of scroll-preserve-screen-position says:

  Scroll commands should have the ‘scroll-command’ property
  on their symbols to be controlled by this variable.

But:

  (get 'scroll-left 'scroll-command) => nil

> 1. emacs -Q --eval '(global-set-key [C-M-right]  (lambda () (interactive) (let ((scroll-preserve-screen-position t)) (scroll-left 3))))'
> 
>    Emacs comes up with the default text in the *scratch* buffer
> 
> 2. (goto-char (point-min))
> 
>    Move the point to the beginning of the buffer. (point) evaluates to 1
> 
> 3. C-M-right
> 
>    We scroll to the right. The point was on the left edge of the screen
>    at position 1, which is now out of view. Emacs still draws the point
>    at the left edge of the screen, implying that the point was moved to
>    stay in-bounds. But this is not where the point actually is: (point)
>    still evaluates to 1. I expect (point) to be updated with the new
>    position

This is the expected behavior.  The Emacs manual says:

     If the text is scrolled to the left, and point moves off the left
  edge of the window, the cursor will freeze at the left edge of the
  window, until point moves back to the displayed portion of the text.

> 4. C-a
> 
>    Now, some commands behave strangely. For instance C-a should move to
>    the start of the line. This is now off-screen, so I would expect
>    emacs to scroll back so that we can see the beginning of the line.
>    But emacs does nothing: the point was at position 1, and it was moved
>    to position 1, so it doesn't see the need to scroll anything.

This is also expected, since horizontal scroll command affect the
automatic hscrolling, as described in the manual:

     If you use those commands to scroll a window horizontally, that sets
  a lower bound for automatic horizontal scrolling.  Automatic scrolling
  will continue to scroll the window, but never farther to the right than
  the amount you previously set by ‘scroll-left’.

Bottom line: if we want scroll-preserve-screen-position to affect
horizontal scrolling in some (as yet to be defined) way, we need to
code that.  Other than that, what you report here is the expected and
documented behavior.

Thanks.

bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view

[Dima Kogan]

Oh wow. Thanks for pointing that out, Eli. I didn't think to go read the
documentation for something so basic-sounding as "scroll-left". I'm not
going to have the cycles to fix it myself in the near future,
unfortunately. Should we close this issue?

bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 50234@debbugs.gnu.org
> Date: Sat, 28 Aug 2021 19:28:30 -0700
> 
> Oh wow. Thanks for pointing that out, Eli. I didn't think to go read the
> documentation for something so basic-sounding as "scroll-left". I'm not
> going to have the cycles to fix it myself in the near future,
> unfortunately. Should we close this issue?

I made it a "wishlist" report, i.e. request for a feature.  I think we
can leave it open in that quality, in case someone wants to implement
it.

Thanks.