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

["Clément Pit--Claudel" <clement.pitclaudel@live.com>]

[-- Attachment #1: Type: text/plain, Size: 2494 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]