bug#31276: 27.0.50; "Spurious" empty first line from before-string

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 31276@debbugs.gnu.org
> Date: Sat, 28 Apr 2018 09:13:18 -0400
> 
> >>     % src/emacs -Q etc/NEWS --eval '(let ((ol (make-overlay (+ (point) 10)
> >> (+ (point) 10)))) (overlay-put ol (quote before-string) "\nhello\n"))'
> >>     C-u 1 C-v
> >> You should see that the "scroll by 1 line" didn't actually scroll: it just
> >> removed the "GNU Emacs " from your sight and left an empty line instead.
> > After "C-u 1 C-v", type C-p, then type "C-u 1 C-v" again.  What do you
> > see?
> 
> I see the display go
> 
>     GNU Emacs
> 
>     hello
>     NEWS ...
> 
> i.e. I get a *really* spurious line.  This one is clearly a bug.

Is it?  The overlay string starts with a newline, and that's what you
see here.  Buffer position 11 is the 'N' of NEWS, and you asked Emacs
to prepend "\nhello\n" to that, which it did.  The newline after
"Emacs", which comes from the buffer text, is still visible.  So why
is this a bug?

> > It sounds very strange to me to do so.
> 
> That was also my first reaction, but redisplay can arguably choose (to
> some extent) at which line it starts the display, so if you skip some
> leading newline you still get a valid result.  The "to some extent" is
> because sometimes the redisplay can't really choose (i.e. when
> window-start has been fixed), but in the current case, even if
> window-start is fixed there are several possible choices of "first line"
> to display, so even in that case the result is still valid.

window-start is a buffer position.  The way redisplay is designed,
scrolling determines which buffer position will serve as window-start,
and then it advises redisplay to use that window-start.  But the only
information passed to redisplay is the buffer position, so we
currently cannot tell redisplay "use that position, but skip
such-and-such parts of the overlay string at that position.  As
result, Emacs will display starting at that position, and the first
thing it finds there is the overlay string.  So it displays that
string.

> > Whoever puts the newlines there does that for a reason,
> 
> To divide the (previous) line, but not to introduce an empty line.

Two consecutive newlines, one comping from buffer text, the other from
an overlay string _must_ produce an empty line.  What else can you
expect?

> > and I'm sure will object to having them effectively removed in
> > some situations.
> 
> I put the newlines there and I definitely would not object.
> Better yet, I'd report a bug if the newline isn't removed.

That's exactly what's strange to me.  You put the newline there, but
you don't want to see it?  Then don't put it there in the first place.
I'm probably missing something here.