Eli Zaretskii<address@hidden> writes:
The following 4 lines define two overlays with display strings, with
the second overlay "nested" inside the first one:
(defvar myov1 (make-overlay 16 51))
(overlay-put myov1 'display "STRING1")
(defvar myov2 (make-overlay 29 43))
(overlay-put myov2 'display "STRING2")
If you evaluate this in the *scratch* buffer, the result is this:
;; This buffer STRING1STRING2STRING1, and for Lisp evaluation.
That is, STRING1 is displayed twice! Is this a bug or a feature?
I asked Gerd Möllmann, and he told me that this is an accident: what
he really meant was, once STRING1 is displayed, to skip to the end of
its overlay, so that the nested overlay myov2 would not be displayed
at all.
I'm of the opinion that it should either display: STRING1 or
STRING1STRING2STRING1, and which doesn't really matter. In the first
case, the first overlay gets a higher priority than the second, in the
latter the second gets one that is higher than the first. The manual
says: "You should not make assumptions about which overlay will prevail
when there is a conflict and they have the same priority." This is what
makes me think that either is correct. If I had to choose, however, I
would prefer that if two overlays with the same priority appear over the
same character, whichever overlay that has the earlier start should take
precedence (giving us STRING1 in this case).
Please note, that if myov1 had a specifically higher priority than
myov2, I think STRING1STRING2STRING1 is a perfectly valid result. I see
overlays and text properties reducing down to a single set of property
ranges, with text properties at a sort-of -1 priority. In this case we
have a range with a property of STRING1, a range with a property of
STRING2, and a range with property of STRING1 again. The display makes
perfect sense to me.