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

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

[Stefan Monnier]

Package: Emacs
Version: 27.0.50


Try the following:

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

Arguably, this is right: `window-start` has to be one of the buffer's
positions, so it has to be either before or after the overlay, and the
overlay's string starts with a line-feed, so if window-start is placed
there, the window will start with an empty line.

But arguably this is also wrong: there is no empty-line at that position
in the buffer's normal rendering.

Whether you consider this as a bug report or a feature request, my point
is that when the window starts with a before/after-string and that
string starts with a line-feed, we should skip that line-feed rather
than waste a perfectly good line.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Thu, 26 Apr 2018 16:11:38 -0400
> 
> Package: Emacs
> Version: 27.0.50
> 
> 
> Try the following:
> 
>     % 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?  Does what you see change your idea about where the bug is?

> Whether you consider this as a bug report or a feature request, my point
> is that when the window starts with a before/after-string and that
> string starts with a line-feed, we should skip that line-feed rather
> than waste a perfectly good line.

I don't understand: are you arguing that we should ignore newlines in
overlay strings when they happen to appear at the beginning of the
window?  It sounds very strange to me to do so.  Whoever puts the
newlines there does that for a reason, and I'm sure will object to
having them effectively removed in some situations.

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

[Stefan Monnier]

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

> Does what you see change your idea about where the bug is?

Not really, but it's probably because my idea of "where the bug is" is
much too vague.

>> Whether you consider this as a bug report or a feature request, my point
>> is that when the window starts with a before/after-string and that
>> string starts with a line-feed, we should skip that line-feed rather
>> than waste a perfectly good line.
> I don't understand: are you arguing that we should ignore newlines in
> overlay strings when they happen to appear at the beginning of the
> window?

Not "in" but "at the beginning of", yes.  Also I'd probably go with
"newline" rather than "newlines", just out of conservatism.

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

> Whoever puts the newlines there does that for a reason,

To divide the (previous) line, but not to introduce an empty line.

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


        Stefan

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.

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

[Eli Zaretskii]

> Date: Sat, 28 Apr 2018 17:04:09 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 31276@debbugs.gnu.org
> 
> >     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?

Answering myself: there's no newline after "Emacs".  So yes, this is a
spurious empty line.  I will see why that happens.