Re: Fwd: overlay face property not used for after-string property

[Joe Wells <jbw@macs.hw.ac.uk>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I think that the before-string should, in effect, use
>> (get-char-property (overlay-start ov) 'face)
>> to determine the face to use if no fully specified face is in the
>> before-string.
>
> No.  Go read the beginning of this thread again where I explained why this
> is bad: it's (much) harder to remove a face than to add one.
>
> Also text-properties should not affect before/after-strings.

Except of course that text properties inside the string itself should
have an effect.

> I believe the
> most obviously sensible rule is to follow the precedence that we always use:
> - overlays take precedence over text-properties

I'll assume by “text-properties” you mean “text properties in the
buffer”.

> - overlays of higher priority take precedence over overlays of lower
>   priority

Does the higher priority overlay need to entirely contain the
lower-priority overlay to have an effect?  What if the overlays
partially overlap, but neither contains the other?  Suppose the end of
overlay o2 is the same as the start of overlay o1:  Can overlay o2's
face affect overlay o1's before-string?

> - for overlays of equal priority if one overlay covers the other it takes
>   precedence

So covering an overlay is like having higher priority?  What if the
two overlays have the same extent?  Does this count as covering?  If
so, do two overlays with the same extent and the same priority cover
each other?

> - for the other cases of equal priority, any arbitrary choice is OK as long
>   as it's deterministic
>
> Given this, a (before|after)-string should only be affected by
> invisible|face properties set by overlays of higher precedence: not by
> text-properties, not be overlays of lower precedence.

So you propose things work by “precedence” which is derived from
“priority” and “covering”?

-- 
Joe