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

[Joe Wells]

David Kastrup <address@hidden> writes:

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

It's not actually an issue of “removing” a face.  The issue is
actually “preventing inheritance” of a face.

>> Also text-properties should not affect before/after-strings.
>
> I don't see why not if they are appropriately sticky.

An example application is linum.el.  This code needs to display
strings at the beginning of each line and the strings need to be
displayed with a face independent of the face of the adjacent text
(regardless of whether there are sticky text properties there).  At
the same time, linum.el should not use a fully specified face because
the face should be affected by the default face of the frame.

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

The idea of “completely resolve to default” sounds interesting
(independently of what we are discussing).

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

The problem is that the existing rules are already illogical and we
are trying to figure out how to make them less illogical.

-- 
Joe