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

[Stefan Monnier]

>> Also text-properties should not affect before/after-strings.
> Except of course that text properties inside the string itself should
> have an effect.

Indeed.

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

Indeed.

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

No.  Note that these rules are general rules about how overlays and
text-properties interact.

> What if the overlays partially overlap, but neither contains the
> other?

In general, this makes no difference...

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

.. in the case of (before|after)-strings, interpreting what this rule
implies is trickier, but I guess it'd be something like:

  the overlays that apply to an (before|after)-string are those that
  have higher precedence than the string's overlay and that would apply
  to text inserted at that position in the buffer.

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

> So covering an overlay is like having higher priority?

Yes.

> What if the two overlays have the same extent?

Then this rule doesn't apply and the next one (the catch-all)
applies instead.

>> - 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”?

Not quite: instead I described how it currently works in general, and
I suggest that we solve our problem w.r.t (before|after)-string by
trying to extrapolate from the existing rules.

I'm not 100% sure the result will be the most convenient in every single
case, but at least it will have the advantage of being conceptually clean.


        Stefan