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

[David Kastrup]

Joe Wells <address@hidden> writes:

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

That's what I say: instead of making the behavior illogical in order
to default to some behavior good for some application, we should add
the facility for the application to explicitly request the behavior it
needs.

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

Because of a bug.

> and we are trying to figure out how to make them less illogical.

What I see happening is that the current bug is used as an excuse to
establish a different inconsistent behavior as "correct", based on
convenience for some applications.  Basically "if we are being
inconsistent, we might as well be inconsistent in a more convenient
manner."

And I do not consider this a good idea.  If the consistent and logical
behavior is inconvenient for some applications, we need to add the
facilities for overriding it.  But the override should not become a
fixed default.

-- 
David Kastrup