bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 29 Sep 2023 13:53:04 +0200
> Cc: 66216@debbugs.gnu.org
> From: Herman, Géza <geza.herman@gmail.com>
> 
> I have scroll-up/down-line mapped to a key. I'd like to see that if I 
> press and hold these keys, Emacs can scroll continuously. It doesn't 
> matter too much if at some position, it jumps 2 (or more) visible lines. 
> Using prefix arguments is not a good solution for this case, because if 
> I have a buffer with a lot of such overlays (like magit's blame buffer), 
> it's very inconvenient that emacs stops very frequently, and then I have 
> to nag it with a prefix argument to "please scroll further". But of 
> course I can try to write some elisp function to work around this 
> limitation.

I explained why catering only to this preference will bring us other
problems.

One solution is for you to write a simple function that scrolls by
more than 1 line if the basic scroll didn't change window-start
position.

And if this is a problem with Magit, then I would suggest that Magit
has its own scrolling function to overcome the problems.  I tried to
explain many times that using overlays and display properties in Magit
buffers was a bad idea, and the Magit developer even agreed with me at
some point.

> As scroll-down-line jumps over overlays, so it already scrolls 2 visible 
> lines in the mentioned case, it would make sense that scroll-up-line 
> behaves the same as well. The current behavior is not consistent. I'd 
> expect that if scroll-down-line moves window start somewhere, then 
> scroll-up-line will undo this. But in this case scroll-down-line will 
> move 2 lines, then scroll-up-line doesn't do anything.

The situation with scroll-down and scroll-up is not symmetric.