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

[Clément Pit--Claudel]

On 01/07/2016 03:35 PM, Eli Zaretskii wrote:
>>> 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.

Yes, sorry for being unclear. Hopefully the following is more clear. For any 
overlay/invisible section pair there are five cases, right?

1. The overlay does not intersect with the invisible area. No problems here.
2. The overlay covers a few characters before the invisible area and the first 
few characters of the invisible area, but not the last ones.
3. The overlay covers a few characters after the invisible area and the last 
few characters of the invisible area, but not the first ones.
4. The overlay is a subset of the invisible area.
5. The overlay is a superset of the invisible area.

The current solution doesn't think in these terms; instead, it ignores all 
overlays for the ellipses, unless the first hidden character has the same face 
as the preceding one.

Always applying the face of the first character to the ellipsis means applying 
to the ellipsis the faces of overlays in categories 2, 5, and 4 if they cover 
the first character. You pointed out that the special case of 4 is confusing.

Another option (the one I was trying to explain above) is to apply to the 
ellipsis only the faces of overlays in category 5. I feel that this should be 
rather uncontroversial (don't you think?).

The problem with this way of thinking about overlays and invisible text is that 
it doesn't necessarily map directly to the implementation. IIUC, the current 
implementation computes faces without taking invisibility into account for the 
first character before and after the left boundary of the invisible section, 
and then compares them. At this point it's too late to merge certain faces but 
not others.

Thanks again for your explanations and your time.

signature.asc
Description: OpenPGP digital signature