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

[Stefan Monnier]

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

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.

Basically, we have:

                      end-of-ol1
                   /              \
    character "t", - after-string - character "\n"
                   \              /
                     start-of-el2

where the middle 3-way thingy has 0 width and we get to treat them as
occurring in any order we like, to some extent (including in several
orders at the same time depending on context).

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.

>> I guess you could pay attention to the stickiness of the boundaries
> I don't think stickiness has anything to do with this.

I'm not saying it explains the current behavior, no.  I'm talking about
what kind of model/semantics we could use to justify the current
behavior, and conclude that indeed stickiness can't be used to
justify it.

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

Agreed.

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

We've used stickiness in various related areas (e.g. in cursor movement)
to try and give some control to the programmer about what should happen
in those borderline cases.

To tell you the truth, I'm not really arguing for the use of
stickiness here.  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 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.

I said "last few chars", not "end-point".


        Stefan