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:

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

Suppose overlay o2 has higher priority than overlay o1 and covers only
part of overlay o1.  Does o2's face affect o1's display property?

>> What if the overlays partially overlap, but neither contains the
>> other?
>
> In general, this makes no difference...

What about overlays' display properties?

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

What is “this rule” here?

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

I like this (at least for before-string and after-string, it is not
clear what happens for overlay display properties).

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

I don't understand why “this rule” doesn't apply in this case.  Can
you explain?

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

Can you write down the full proposed rule set in plain English?  I'm
getting lost trying to follow.

-- 
Joe