Re: before- and after-string issues

[Kim F. Storm]

> B. After-string precedes before-string
>
> Let OA and OB denote two different empty overlays residing at the same
> buffer position.  If OB has a before-string and OA has an after-string
> the after-string is displayed in front of the before-string.  The
> barrier sketched above would handle this in a more intuitive way.


This is by design -- this is explicitly documented in the source code:


/* Compare two overlay_entry structures E1 and E2.  Used as a
   comparison function for qsort in load_overlay_strings.  Overlay
   strings for the same position are sorted so that

   1. All after-strings come in front of before-strings, except
   when they come from the same overlay.

   2. Within after-strings, strings are sorted so that overlay strings
   from overlays with higher priorities come first.

   2. Within before-strings, strings are sorted so that overlay
   strings from overlays with higher priorities come last.

   Value is analogous to strcmp.  */


I don't know why it is this way, but changing this may break existing
code.  And I cannot find anything in the lisp reference which document
this behaviour.

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 don't know what to do about it.

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