bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#22320: Overlays with an 'invisible property break stacking of overlay faces
Date: Fri, 08 Jan 2016 12:28:05 +0200

> Cc: address@hidden
> From: Clément Pit--Claudel <address@hidden>
> Date: Thu, 7 Jan 2016 19:27:30 -0500
> 
> 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.

In this case, Emacs doesn't care where the overlay ends, that buffer
position is skipped without checking overlays.

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

Likewise.

> 4. The overlay is a subset of the invisible area.

If it starts on the first invisible character, Emacs will take note;
otherwise it won't.

> 5. The overlay is a superset of the invisible area.

This is the case with all your use cases.

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

Well, now that I've committed what I believe is a better solution, I
think we can put these issues to rest.

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

Yes.  More accurately, the display engine always considers faces
before it considers invisibility, so it always sees the face of the
first invisible character.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]