[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: David Kastrup
Subject: Re: Fwd: overlay face property not used for after-string property
Date: Mon, 05 Nov 2007 16:04:24 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux)

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

Then our problem is that it is much harder to remove a face than to
add one.  And that is the problem we should fix.

> Also text-properties should not affect before/after-strings.

I don't see why not if they are appropriately sticky.

> I believe the most obviously sensible rule is to follow the
> precedence that we always use: - overlays take precedence over
> text-properties - overlays of higher priority take precedence over
> overlays of lower priority - for overlays of equal priority if one
> overlay covers the other it takes precedence - 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.

Resolving partially specified faces goes through priorities.  If there
are usage cases for before/after-string that should not inherit, then
we need to add a way to say "completely resolve to 'default (or
whatever other face) here".  Then things like lineno can use that way.

But it does not make sense to substitute a missing facility with some
fixed but illogical rules that cater for some but not all use cases
because it is easier to override this in that manner.

David Kastrup

reply via email to

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