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

[Herman@debbugs.gnu.org, 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.

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.

On 9/29/23 13:28, Eli Zaretskii wrote:
>> Date: Tue, 26 Sep 2023 20:30:53 +0200
>> From: Herman@debbugs.gnu.org, Géza <geza.herman@gmail.com>
>>
>> This bug exists in 28.2, but on a not too old master as well.
>>
>> Repro:
>>    - emacs -Q
>>    - M-: (overlay-put (make-overlay 72 72) 'before-string "Fake line\n")
>>    - this will put a "Fake line" at the 2nd line of the scratch buffer,
>> (between the two default scratch buffer message lines)
>>    - M-x scroll-up-line
>>    - this will correctly scroll one line up
>>    - M-x scroll-up-line
>>    - this is the bug, no scroll happens
>>
>> Also, if the overlay is added at the middle of some line (not at the
>> beginning like in my repro steps), then scroll-up-line will "scroll"
>> until the overlay only, making the overlay to visually move the left
>> side. Then further scroll-up-line commands won't have an effect.
> What do you expect to happen in these cases?
>
> The scroll commands work by telling Emacs which buffer position to use
> as the window-start for the next redisplay; then redisplay kicks in
> and redraws the window using that starting position.  But for boring
> technical reasons, Emacs is unable to start displaying a buffer from a
> position where we have a before-string overlay, without displaying
> that before-string first.  Which is what you see.
>
> We could scroll one more line in these cases, but then the other group
> of users will come up complaining that we scroll over too much text
> (no one said the before-string must have only one newline, it could
> have several ones, in which case we will scroll across all of those
> lines).  So we punt and let the user invoke the scrolling commands
> with an appropriate prefix argument; for example, in this case, just
> say "C-u 2 M-x scroll-up-line RET", and Bob's your uncle.
>
> But if this is not good enough, please tell what you'd like to see
> instead, given the above limitation of the current display engine, and
> maybe we will find better solutions for this conundrum.
>
> Thanks.