bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Kevin Liu]

This has been a bug since at least 24.x, and I think Eli even fixed
something like it once before:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2012-11/msg00838.html

This problem is a little different because it involves scroll-margin.
When scrolling up, the cursor will seem to ignore it until it hits the
top, and then jumps back down to the margin.

To quickly reproduce this, run emacs -Q and then eval

(progn
 (global-hl-line-mode)
 (setq scroll-margin 5)
 (setq scroll-conservatively 101)
 (view-hello-file)
 (end-of-buffer))

Then (previous-line) until you see the problem.

Further reference:
- https://emacs.stackexchange.com/questions/48340/line-numbers-break-scroll-margin
- https://github.com/syl20bnr/spacemacs/issues/8224

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Eli Zaretskii]

> From: Kevin Liu <kevin@nivekuil.com>
> Date: Sat, 01 Aug 2020 03:39:57 -0700
> 
> (progn
>  (global-hl-line-mode)
>  (setq scroll-margin 5)
>  (setq scroll-conservatively 101)
>  (view-hello-file)
>  (end-of-buffer))
> 
> Then (previous-line) until you see the problem.

I only see this when EOB is before end of the window, which I don't
think is a bug.

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Kevin Liu]

On  1 August 2020 09:44, Eli Zaretskii <eliz@gnu.org> wrote:

> I only see this when EOB is before end of the window, which I don't
> think is a bug.

Could you elaborate on this?  I don't understand why it's proper for
hl-line-mode and display-line-numbers-mode to affect scrolling behavior
in any scenario, much less this one.

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Eli Zaretskii]

> From: Kevin Liu <kevin@nivekuil.com>
> Cc: 42653@debbugs.gnu.org
> Date: Sat, 01 Aug 2020 10:32:13 -0700
> 
> On  1 August 2020 09:44, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I only see this when EOB is before end of the window, which I don't
> > think is a bug.
> 
> Could you elaborate on this?  I don't understand why it's proper for
> hl-line-mode and display-line-numbers-mode to affect scrolling behavior
> in any scenario, much less this one.

Indeed, they shouldn't.  I've misinterpreted the test case, sorry.

There was a 15-year old code that handled the logic of scroll-margin
when EOB is visible, and it had a bug.  This should now be fixed on
the master branch.

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Kevin Liu]

Thanks!  This has honestly bugged me forever and will improve my Emacs
experience immeasurably.

> /* if EOB is visible, disable bottom margin */

This is a very interesting change that I didn't know I wanted, and I
really like it.  I see two issues right now:

1. If (hl-line-mode 1), then scrolling down as you reach EOB will
continue "collapsing" the margin, moving the cursor but not scrolling
beyond EOB, until it hits the actual EOB line.  At that point,
scroll-margin will again take effect and the screen will suddenly scroll
down by scroll-margin lines (7 in my case).  This seems like a bug,
off-by-one maybe?

2. The intended behavior of disabling the bottom margin as EOB
approaches seems to only apply when (hl-line-mode 1) or
(display-line-numbers-mode 1).  This means that enabling these modes
still affects scrolling behavior, which I think is fundamentally
unexpected.

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Eli Zaretskii]

> From: Kevin Liu <kevin@nivekuil.com>
> Cc: 42653@debbugs.gnu.org
> Date: Sun, 02 Aug 2020 13:24:34 -0700
> 
> 1. If (hl-line-mode 1), then scrolling down as you reach EOB will
> continue "collapsing" the margin, moving the cursor but not scrolling
> beyond EOB, until it hits the actual EOB line.  At that point,
> scroll-margin will again take effect and the screen will suddenly scroll
> down by scroll-margin lines (7 in my case).  This seems like a bug,
> off-by-one maybe?
> 
> 2. The intended behavior of disabling the bottom margin as EOB
> approaches seems to only apply when (hl-line-mode 1) or
> (display-line-numbers-mode 1).  This means that enabling these modes
> still affects scrolling behavior, which I think is fundamentally
> unexpected.

Please show a test case for each of these two, as I don't think I've
seen them in my testing.

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Kevin Liu]

On  2 August 2020 19:28, Eli Zaretskii <eliz@gnu.org> wrote:

> Please show a test case for each of these two, as I don't think I've
> seen them in my testing.

My original test case should demonstrate this as well, as the buffer
should be scrolled beyond EOB.  Then (previous-line) up until EOB is
back out of view, then scroll back down and the problem should be
visible.  I also recorded a video for illustration in case this is one
of those only-on-my-machine cases (which it might be, as I built off a
merged native-comp branch): https://www.youtube.com/watch?v=EKrbrVGbEZw

(progn
  (global-hl-line-mode)
  (setq scroll-margin 5)
  (setq scroll-conservatively 101)
  (view-hello-file)
  (end-of-buffer))

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Eli Zaretskii]

> From: Kevin Liu <kevin@nivekuil.com>
> Cc: 42653@debbugs.gnu.org
> Date: Sun, 02 Aug 2020 20:18:20 -0700
> 
> On  2 August 2020 19:28, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Please show a test case for each of these two, as I don't think I've
> > seen them in my testing.
> 
> My original test case should demonstrate this as well, as the buffer
> should be scrolled beyond EOB.  Then (previous-line) up until EOB is
> back out of view, then scroll back down and the problem should be
> visible.  I also recorded a video for illustration in case this is one
> of those only-on-my-machine cases (which it might be, as I built off a
> merged native-comp branch): https://www.youtube.com/watch?v=EKrbrVGbEZw
> 
> (progn
>   (global-hl-line-mode)
>   (setq scroll-margin 5)
>   (setq scroll-conservatively 101)
>   (view-hello-file)
>   (end-of-buffer))

Very well, I've now removed the EOB test.

bug#42653: Emacs now recentering very aggressively

[Dale Sedivec]

Hi, as of commit a07ec21bf24b, which is said to address bug #42653, Emacs started recentering as I scroll up.  Here's a minimal reproduction case:

1. emacs -Q

2. Display anything in the header line: (setq-default header-line-format "foo")

3. Open any file longer than a few screenfuls: M-x find-library RET subr RET

4. Enable which-function-mode: M-x which-function-mode RET

(display-line-numbers-mode also triggers this problem, but I find which-function-mode more interesting since it doesn't change the display of the buffer at all, only the mode line.)

5. M-> (end-of-buffer)

6. Page up a few times with M-v (scroll-down-command)

Expected behavior: Point is sitting at the bottom line of the window no matter how many times you page up

Observed behavior: The window is recentered, usually after ever page up, with a slight delay

Here's a video of this behavior, in case it helps: https://www.dropbox.com/s/i7m2h9ltwrpxxy3/emacs_scrolling.mp4?dl=0

emacs-version: GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6020)) of 2020-09-10

I built this today from master, 70a8d06fe1.

I can stop this from happening with (setq scroll-conservatively 101), so perhaps the behavior is intentional?  However, the fact that point stays at the bottom of the window for a brief instant, and then only recenters when (I am **guessing**) which-func-update runs leads me to believe this is unintentional behavior.

Please let me know if you need any more information.

Regards,
Dale

bug#42653: Emacs now recentering very aggressively

[Lars Ingebrigtsen]

Dale Sedivec <dale@codefu.org> writes:

> 2. Display anything in the header line: (setq-default header-line-format "foo"
[...]

> Expected behavior: Point is sitting at the bottom line of the window
> no matter how many times you page up
>
> Observed behavior: The window is recentered, usually after ever page
> up, with a slight delay

Ah!  So that's what this is.  I spent some time the other day tracking
down why this was happening in erc buffers, so I was looking at recent
erc changes.  But erc is one of the few modes I have with a header line
that I sometimes scroll back in, so that explains it.

> I can stop this from happening with (setq scroll-conservatively 101),
> so perhaps the behavior is intentional?  However, the fact that point
> stays at the bottom of the window for a brief instant, and then only
> recenters when (I am **guessing**) which-func-update runs leads me to
> believe this is unintentional behavior.

Yes, it's definitely unintentional.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#42653: Emacs now recentering very aggressively

[Eli Zaretskii]

> From: Dale Sedivec <dale@codefu.org>
> Date: Thu, 10 Sep 2020 16:18:55 -0500
> 
> 1. emacs -Q
> 
> 2. Display anything in the header line: (setq-default header-line-format "foo")
> 
> 3. Open any file longer than a few screenfuls: M-x find-library RET subr RET
> 
> 4. Enable which-function-mode: M-x which-function-mode RET
> 
> (display-line-numbers-mode also triggers this problem, but I find which-function-mode more interesting since it doesn't change the display of the buffer at all, only the mode line.)
> 
> 5. M-> (end-of-buffer)
> 
> 6. Page up a few times with M-v (scroll-down-command)
> 
> Expected behavior: Point is sitting at the bottom line of the window no matter how many times you page up
> 
> Observed behavior: The window is recentered, usually after ever page up, with a slight delay

Thanks, there was a subtle thinko in commit a07ec21bf24b, should be
fixed now.

bug#42653: 28.0.50; scroll-margin is sometimes ignored with hl-line/display-line-numbers-mode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, there was a subtle thinko in commit a07ec21bf24b, should be
> fixed now.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I'm therefore closing this bug report.  If there's still a bug here,
please respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no