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

[Joe Wells]

Joe Wells <address@hidden> writes:

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

An additional point.  Suppose the overlay has both before-string and
display properties.  (Yes, you need to do this if you want to use an
overlay to replace the text in the buffer and display multiple images
or a mixture of text and images.)  The display property replaces the
display of the text in the buffer (and possibly specifies a different
face for it).  It makes no logical sense in this case for the display
of the before-string to use the face of a character in the buffer that
is being concealed.

-- 
Joe

> 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