GNU bug report logs - #50234
28.0.50; Horizontal scrolling doesn't keep the point in view

Previous Next

To reply to this bug, email your comments to 50234 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Horizontal scrolling doesn't keep the point in view
Date: Sat, 28 Aug 2021 00:40:57 -0700

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!

Message #8 received at 50234 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 50234 <at> debbugs.gnu.org
Subject: Re: bug#50234: 28.0.50;
 Horizontal scrolling doesn't keep the point in view
Date: Sat, 28 Aug 2021 11:35:32 +0300

tags 50234 wishlist
thanks

> From: Dima Kogan <dima <at> 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.

Message #13 received at 50234 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50234 <at> debbugs.gnu.org
Subject: Re: bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point
 in view
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?

Message #16 received at 50234 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 50234 <at> debbugs.gnu.org
Subject: Re: bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point
 in view
Date: Sun, 29 Aug 2021 09:43:32 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 50234 <at> 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.

Previous Next

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