bug#22320: Overlays with an 'invisible property break stacking of overlay faces

[Eli Zaretskii]

> Cc: 22320@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Thu, 7 Jan 2016 14:28:09 -0500
> 
> >> Why is this better than, for example, keeping the face of the first 
> >> invisible character and extending it to the whole ellipsis?
> > 
> > That would go back to the original problem, whereby each ellipsis
> > could have a different face depending on the faces in the invisible
> > text.
> 
> No, my proposal would be to make all three dots use the face of the first 
> hidden character.

Yes, I understand.  But then each invisible text will pass its
potentially different face to its ellipsis, so each ellipsis will
generally look different.

> > I think it's confusing to have the faces of the invisible text
> > show through, don't you agree?
> 
> Not really; in a sense they already show through, since changing the faces of 
> the hidden text can change the way it's displayed. Applying the face of the 
> first hidden character to all three dots of the ellipsis has multiple 
> advantages:
> 
> * If an incorrectly spelled word is invisible, the dots are underlined.

If seeing an ellipsis highlighted as a misspelled word is not
confusing to you, then I guess we have very different ideas of what's
confusing...

> * If the first hidden character in fact does have the same face (from the 
> user perspective) as the preceding one, the ellipsis is never reset to the 
> default face (the font fallback issue means that at the moment I can have 
> perfectly uniform-looking text, and folding still gives the default face to 
> the ellipsis).

If the invisible text uses a different font, you will have the
ellipsis displayed with that different font, out of the blue.  It
could, for example, be a much larger or a much smaller font.  Maybe
it's not confusing to you, but it definitely is to me.

> Invisible text is often used for folding sections of a buffer. Folding hides 
> information, but we have an opportunity to show some of that information; 
> namely, the information carried by the first invisible character. The current 
> solution does take the information contained in the first character into 
> account, but then makes it stand out or not based on a complex criterion.

My POV is that when you make text invisible, you don't want to see it.
None of it, not even its colors or its font.  Having some of its
attributes show through is just plain wrong, IMO.

> In fact, I wonder if this isn't two problems we're looking at: the first one 
> is falling back to default, and the second one is that falling back to 
> default ignores the surrounding overlays. My ideal solution would be to use 
> the first hidden character (or make it configurable), but even without this I 
> feel that it would be a progress for the *face* of the ellipses to be reset 
> to default, and then for that face to be merged with overlays. In other word 
> one would consider that ellipses always have the default face, plus overlays 
> that cover the full ellipsis.

Any non-default face is always merged with the default, so saying
let's merge it with the default is asking for a no-op.  It will change
nothing.

What the code does is it deliberately ignores the faces specified by
the overlays (or text properties) put on the invisible text, if that
face is different from the preceding visible text.  We can either
ignore that face or not ignore it; there's no 3rd way.  The way you
suggest is go back to what we've been doing before that 2005 change.
I don't like going back in principle (where does that end? can someone
tomorrow go back from our going back, just because they think they are
right and going back was wrong?).  And I don't think it's justified to
go back in this case.  If someone comes up with a clever idea to fix
more use cases that have faces on invisible text, that would be
progress.  But returning to what we did back then doesn't sound right
to me, so I don't think we should do it.

> >> Am I mistaken to think that this choice is also inconsistent with the way 
> >> faces on composed characters are handled? It seems that composing a 
> >> sequence of characters into "..." will keep the face of the first compose 
> >> character. That default is useful in many places (such as Arthur's 
> >> nameless mode, or in flyspell or flycheck when an error covers a sequence 
> >> of characters composed into a single one). Is there a good reason to treat 
> >> ellipses standing for invisible spans differently?
> > 
> > I'm not sure I understand what you describe here.  Can you show me
> > some simple Lisp which demonstrates the situation?
> 
> Sure (also posted in reply to your other message):

Composed characters are processed, while invisible text is simply
skipped.  That's a world of difference.  Each of these 2 features was
introduced for a very different purpose, so it's small wonder they
produce different effects on display.

> Inheriting the face of the first character and applying it to the whole 
> ellipsis would work here.

But will fail elsewhere.

> >>    Works:  GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 
> >> 3.10.8) of 2015-06-17 on clem-w50-mint
> >>    Broken: GNU Emacs 24.5.2 (x86_64-unknown-linux-gnu, GTK+ Version 
> >> 3.10.8) of 2015-06-20 on clem-w50-mint
> >>
> >> Is this something that changed in org then?
> > 
> > No, nothing changed.  Which version of Org did you use in each Emacs
> > release?  (I used the one bundled with that release.)
> 
> I'm using the bundled Org with emacs -Q in both cases.

Then I don't know what to think.  I see the "gap" in the region face
in all old versions, exactly like I see in 24.5 and in the current
emacs-25 branch.

> >> Indeed, I use aspell instead of ispell. It seems to ignore numbers, and 
> >> thus flags the first two instances of "line" as duplicates.
> > 
> > And what problems do you see then?
> 
> aspell marks line2 as a doublon, places an underline on it, and thus the 
> invisible text doesn't inherit the selection face when I mark the whole 
> buffer.

Ah, you never said the 3rd use case needs "C-x h" as well.

Yes, I see that here, too.  It's the same situation as in the other
cases.