[Top][All Lists]

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

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

From: Stefan Monnier
Subject: Re: Fwd: overlay face property not used for after-string property
Date: Mon, 05 Nov 2007 14:38:46 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux)

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

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?


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


reply via email to

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