[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joe Wells
Subject: Re: Fwd: overlay face property not used for after-string property
Date: Mon, 05 Nov 2007 12:05:39 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

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.


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]