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

[Joe Wells]

David Kastrup <address@hidden> writes:

> Richard Stallman <address@hidden> writes:
>
>>     I think this information may not be enough.  I think the policy
>>     would also need to know which of the overlay properties
>>     before-string, display, or after-string the string comes from.
>>
>> In most cases you can determine this by looking at the overlay's
>> properties and seeing where the string appears.  That will work except
>> when the overlay has two properties that contain strings that are eq.
>>
>> That is not good enough for the final implementation, but it is good
>> enough for experimenting to find the right criteria.  If the right
>> criteria really depend on this information, we can add a mechanism to
>> provide the information efficiently and reliably.  So I see no need to
>> do that until we know whether it is needed.
>
> 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.

The behavior you propose is currently used and causes problems.  I
have complained about it (in separate messages) as a bug.  I have seen
it causing problems for linum.el and tex-fold.el.

When (eq (overlay-start o) (overlay-end o)), the character after
(overlay-start o) is not even inside the overlay.  It makes no logical
sense for the face of a character not covered by the overlay to affect
the display of things specified by the overlay.

Requiring the face of a string displayed by an overlay to be fully
specified means that such a face can never adjust automatically to
changes in other faces.  Yet this is needed.  For example, if the
default face is changed (e.g., to change the overall size of the text
for easier viewing), it is desired that all faces will automatically
adjust.  Similarly, if the region is activated, it would be nice if
all faces that do not need to specify a background would get the
background of face “region”.  With your proposal (which is already
implemented), an overlay's before-string would have to specify a
background color (even if merely white) and could not automatically
pick up the background of the region face.

I would like to strongly suggest that overlay before-string, display,
and after-string properties should *not* be affected by the
text-property face properties in the buffer.

> Similarly for after-string.  That's simple, clear and straightforward
> for the user to understand.  It also has the "right thing" feeling to
> it, which ignoring surrounding faces doesn't.

It definitely has the “wrong thing” feeling to it for me.

-- 
Joe