[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: Joe Wells
Subject: Re: Fwd: overlay face property not used for after-string property
Date: Mon, 05 Nov 2007 21:59:49 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Stefan Monnier <address@hidden> 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.


reply via email to

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