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