emacs-devel
[Top][All Lists]
Advanced

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