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

[Joe Wells <jbw@macs.hw.ac.uk>]

Richard Stallman <rms@gnu.org> writes:

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

(And by the way, this would be easier and less awkward if at least one
additional level of string display property inside overlay display
property was supported.  But this doesn't affect the issue we are
discussing here.)

>     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.
>
> In some cases it does.  Consider a paragraph that is italicized
> with a text property.  Shouldn't substitute text be italic by
> default?

Counterexample: linum.el.

I think priorities are probably the solution.  Here is an idea.  Each
face property and each piece of text has a priority.  A face property
can only affect text of strictly lower priority.  The before-string,
display (if a string), and after-string properties of an overlay have
the priority of their overlay.  Text in the buffer has priority 0.
The face property of an overlay has the priority of that overlay.  A
text property face property (i.e., in a string or in the buffer) has
the priority of the piece of text plus 0.5 (so that it will affect the
text it belongs to).

Comments?

-- 
Joe