Re: before- and after-string issues

[Kim F. Storm]

martin rudalics <address@hidden> writes:

> However, the author of the fix forgot to handle the case of _two_ empty
> overlays at the same position where one has a before- and the other an
> after-string.  Patching this would not break any existing code.
> `compare_overlay_entries' would simply have to consider the length of
> the overlays it has to compare.  Invisible overlays are - unofficially -
> handled like empty overlays; according to `xdisp.c' their start and end
> positions are "indistinguishable".  I believe their before- and
> after-strings are nevertheless sorted based on the actual length of the
> overlay.  In any case, it might make sense to check this.

Can you suggest a patch for this?

>
>  > Worse, the following paragraph seems to indicate that the priority is
>  > not about ordering multiple after- and before-strings, but selecting
>  > just ONE before- and/or after-string to show.
>  >
>  > @kindex priority @r{(overlay property)}
>  > This property's value (which should be a nonnegative integer number)
>  > determines the priority of the overlay.  The priority matters when two
>  > or more overlays cover the same character and both specify the same
>  > property; the one whose @code{priority} value is larger takes priority
>  > over the other.  For the @code{face} property, the higher priority
>  > value does not completely replace the other; instead, its face
>  > attributes override the face attributes of the lower priority
>  > @code{face} property.
>  >
>
> I'd say that _all_ before- and after-strings are shown (at least once).

So the lispref is wrong.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk