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 15:15:29 -0400
> 
> >> 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.
> 
> Yes, but that doesn't mean that the second overlay *covers* the end of
> the first.  Whether/when we consider it to cover is something we get
> to decide.

You are talking about "covering" here, and I think this discloses the
mental bias in understanding how before- and after-strings work.
Unlike most other overlay properties, they do not supply any
attributes to the characters "covered" by the overlay.  Instead, they
have effect only at two places: the beginning and the end points of
the overlay.  Consequently, we check for them only when we are about
to display something at these two positions.  And in this case, the
end point is invisible, so we never check any after-strings there.

And yes, this is due to the order of checking for various display
features: invisibility is tested before the overlay strings.  But
there's a good reason for that order, and "fixing" this dubious use
case, should we decide doing that, will probably be messy due to the
need to avoid displaying the same overlay string twice.  So I suggest
that we instead accept this as deliberate and correct behavior.

> Currently, it seems that the ordering chosen in this specific example is
> something like
> 
>    A) character "t", end-of-ol1, start-of-ol2, after-string, character "\n"
> or
>    B) character "t", start-of-ol2, end-of-ol1, after-string, character "\n"
> or
>    C) character "t", start-of-ol2, after-string, end-of-ol1, character "\n"
> 
> I.e. start-of-ol2 is taken to occur before the after-string, which is
> why the after-string is made invisible.

We don't test for start-of-ol2, we test whether text at that position
is invisible, for whatever reason (it could be a text property or an
overlay property).

> I'd be perfectly happy with a rule "if the last char covered by the
> overlay is visible, then the after-string is also visible" (which is
> what I meant by "attached to the end").

I tried to explain above why thinking about "covered by" is wrong when
overlay strings are involved.