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

[Stefan Monnier]

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

Note that I was not talking about "after-string covering something" but
about "the invisibility overlay covering the after-string".  For the
`invisible` property, "covering" is very much meaningful, AFAIK.

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

Here's my use-case:
I have an org-like mode where I add a kind of "summary" of the content
of each section as an after-string on the header (think of it as the
number of sub-sections or the number of words).  This works great as
long as that section is not folded, but as soon as I fold it, the
summary disappears (along with the body, but that part is clearly
intended).  This summary is handy when the section is unfolded but it
would be even more useful when the section is folded.

I wouldn't want to insert those as actual buffer text because they
shouldn't be saved, so it would be a hassle to tweak the save and
auto-save machinery to remove those.

So I'd prefer to keep this as an "unfixed bug".

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

I'm not talking about the string covering something, I'm talking about
the string's overlay.  IIUC what you're saying is that the connection
between the two is difficult to recover, in the current code.


        Stefan