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

[Joe Wells]

David Kastrup <address@hidden> writes:

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

The current behavior is illogical, so I don't understand your
complaint.

Also, I believe adding a feature to try to block inheritance in some
cases will lead to a specification that is too complicated to
understand.  It is simpler to have fewer inheritances occur in the
first place.

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

I agree that there is a bug.  I don't know what you think the bug is.
For me, the bug is that a face given by a text property in the buffer
can affect the display of before-string and after-string properties of
overlays.

I would be willing to allow this for overlays with negative priority.
That could be a useful meaning for negative priorities (which
currently have no meaning).

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

Actually, we are trying to propose a more consistent behavior (which
is also more useful).

> Basically "if we are being
> inconsistent, we might as well be inconsistent in a more convenient
> manner."

I think it is perfectly consistent to think “only higher priority face
properties affect a piece of text”, with text properties in the buffer
being considered to have the lowest priority (or priority zero if we
now decide to allow negative overlay priorities).

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

As I mention above, I think adding a facility for preventing certain
cases of face inheritance will make things too complicated, and it is
better to remove the problematic cases of inheritance.

-- 
Joe