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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 31067@debbugs.gnu.org
> Date: Fri, 06 Apr 2018 08:28:38 -0400
> 
> > 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.

Indeed.  The problem here is that the invisibility overlay covers the
position where displaying the after-string should be considered.

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

Fine with me (I still hope that leaving such issues will some day
attract volunteers who'd like to do their share of hacking the display
code).

Alternatively, you could, either:

 . separate the invisible text and the after-string with some
   character, or
 . use the 'invisible' text property instead of an overlay

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

No, I'm saying that the only connection is the 2 end-points of the
overlay.  The fact that some text is or isn't in-between is
irrelevant.  Talking about "covered text" in this case is detrimental
to understanding how the feature works, because it tends to force us
to think about after-string as being in some sense "related" to the
"covered" text.  It isn't.