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

[Joe Wells]

Richard Stallman <address@hidden> writes:

>     I agree that it is simple and clear.  However, given the point
>     you made above, I think it would be better if before-string and
>     after-string properties were affected by the face property of
>     other overlays (regardless of whether they should be affected by
>     the face property of the same overlay).
>
> Do you mean ALL other overlays?
>
> So if there are two overlays A and B, A's before-string shoud be
> affected by B's face and vice versa?  That doesn't sound quite right
> to me, but I don't have a feel for just what would be right.

Neither do I.

I would expect if someone put an overlay that contains the entire
buffer, this would affect all things displayed in the buffer from
overlays at lower priority.

I would expect if overlay o2 completely contains overlay o1 and
overlay o2's priority is higher than overlay o1's priority, then
overlay o2's face would affect all things displayed by overlay o1.

The above items seem clearly right.  However, a lot of strange corner
cases arise.

What if overlay o1 and overlay o2 cover the exact same region and have
the same priority?  Should they affect the display of each other's
before-string, display, and after-string properties?

What if

  (and (<= (overlay-start o2)         (overlay-start o1))
       (<= (overlay-start o1)         (overlay-end o2))
       (<  (overlay-end o2)           (overlay-end o1))
       (<  (overlay-get o1 'priority) (overlay-get o2 'priority)))

?  Should overlay o2's face affect overlay o1's before-string (but not
its after-string)?

And there are other cases to consider.

Comments from people who have implemented stuff using overlays would
be welcome here.

> So I have installed a change that makes available, to the function to
> choose the base face, the overlay from which the overlay string came.
> The function is now called `face_for_overlay_string', and it is in
> xfaces.c.  Given that info, people could implement whatever policy
> seems right.

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.  (Note that coming
from an overlay's display string is distinct from coming from a
display string as a text property on an overlay's before-string, which
should count as coming from the before-string.)

-- 
Joe

> But I don't want to try implementing a different policy myself.  I
> don't have an actual use for this feature, so I could try five
> different policies with no reason to expect any of them to be good for
> actual use.
>
> I will leave this part for others.