[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Nested display strings

From: Drew Adams
Subject: RE: Nested display strings
Date: Sat, 23 Apr 2011 13:31:47 -0700

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

Don't `display' and `priority' get along well, or can't they be be made to get

We have two overlapping overlays here, and the usual way to determine what
happens when overlays overlap is by looking at their `priority' values (among
other things).

> However, after so many years (this is how Emacs behaves since v21.1),
> perhaps we should keep this behavior.  Does anyone know any real-life
> use cases where this "feature" is needed or would be beneficial?

Dunno whether any existing code depends on the current behavior.  But I would
tend to think of both the current behavior and what Gerd proposed as less than

If `display' and `priority' can be made to cooperate then that would be good.
In that case, the behavior would be consistent with other uses of overlapping

Actually, the doc seems to suggest the behavior that I would expect.
(elisp) `Display Property' says:

"If several sources (overlays and/or a text property) specify values
for the `display' property, only one of the values takes effect,
following the rules of `get-char-property'.  *Note Examining

And (elisp) `Examining Properties' says this about `get-char-property':

"If OBJECT is a buffer, then overlays in that buffer are
considered first, in order of decreasing priority, followed by the text

IOW, it seems to say that even in the case of overlapping overlays, each with a
`display' property, one of the overlays wins completely, and deciding which one
wins involves taking `priority' into account.

If the doc is taken as what should happen, then the current behavior would seem
to represent a bug.  Gerd's proposed behavior apparently also conflicts with the
documented behavior: `priority', not just first-come-first-served, should govern
what happens.

You raise a good question, in any case.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]