all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view
@ 2021-08-28  7:40 Dima Kogan
  2021-08-28  8:35 ` Eli Zaretskii
  0 siblings, 1 reply; 4+ messages in thread
From: Dima Kogan @ 2021-08-28  7:40 UTC (permalink / raw)
  To: 50234

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!





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view
  2021-08-28  7:40 bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view Dima Kogan
@ 2021-08-28  8:35 ` Eli Zaretskii
  2021-08-29  2:28   ` Dima Kogan
  0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2021-08-28  8:35 UTC (permalink / raw)
  To: Dima Kogan; +Cc: 50234

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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view
  2021-08-28  8:35 ` Eli Zaretskii
@ 2021-08-29  2:28   ` Dima Kogan
  2021-08-29  6:43     ` Eli Zaretskii
  0 siblings, 1 reply; 4+ messages in thread
From: Dima Kogan @ 2021-08-29  2:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50234

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?





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view
  2021-08-29  2:28   ` Dima Kogan
@ 2021-08-29  6:43     ` Eli Zaretskii
  0 siblings, 0 replies; 4+ messages in thread
From: Eli Zaretskii @ 2021-08-29  6:43 UTC (permalink / raw)
  To: Dima Kogan; +Cc: 50234

> 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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-08-29  6:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-08-28  7:40 bug#50234: 28.0.50; Horizontal scrolling doesn't keep the point in view Dima Kogan
2021-08-28  8:35 ` Eli Zaretskii
2021-08-29  2:28   ` Dima Kogan
2021-08-29  6:43     ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.