bug#31067: 27.0.50; After-string hidden by subsequent invisible text

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 31067@debbugs.gnu.org
> Date: Thu, 05 Apr 2018 11:55:43 -0400
> 
> >> If some (or all) of the end of the overlay-with-after-string is made
> >> invisible, then the situation is much less clear and I could see
> >> arguments either way, but if I get to choose then I think it makes sense
> >> to consider that the after string is "attached" to the end of the
> >> overlay, i.e. if the end of the overlay is invisible then so is the
> >> after-string.
> > But that's exactly what happens in your original example.
> 
> Hmmm.... not that I can see: the overlay covers "text" and none of it
> is hidden.

The overlay's end point is _after_ "text", and that's exactly where
the invisible text starts.  And after-string _follows_ the end of
"text", so it starts where the invisible text starts.

> I guess you could pay attention to the stickiness of the boundaries

I don't think stickiness has anything to do with this.  I could
explain how the particular implementation of these features causes the
after-string to be skipped in this case, but I prefer that we first
establish the principles and the concepts.  From my POV, the
implementation does what it does because it considers after-string,
conceptually, to _follow_ the end-point of the overlay, and in this
case what follows it is invisible.

> And think this one is even more
> clearly a bug, because according to stickiness the two overlays "don't
> touch" (as can be tested by carefully moving point right after the "t" and
> inserting "-" which gives you a display of "text!after!-" showing that
> the "-" was inserted between the two overlays rather than into the
> first or into the second or into both).

They cannot "not touch", because there's nothing between 'after
"text"' and 'before the following point'.  The fact that inserting a
character behaves in some specific way doesn't matter, because the
display engine doesn't (and shouldn't) consider stickiness, it only
considers which display elements follow which.

> I meant "if the last few chars covered by the overlay (or the whole
> text covered by the overlay) is made invisible ...".

And that's what happens: the overlay's end-point is made invisible.