[Top][All Lists]

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

Re: Nested display strings

From: Andreas Röhler
Subject: Re: Nested display strings
Date: Sat, 23 Apr 2011 21:42:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20110303 Thunderbird/3.1.9

Am 23.04.2011 18:44, schrieb Eli Zaretskii:
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.

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?

The reason I'm asking is that whether we keep or remove this feature
affects the detailed design of how bidirectional text should be
reordered in the presence of display properties and overlay strings.


would consider it definitly a bug with respect of
following order of evaluation:

(defvar myov2 (make-overlay 29 43))
(defvar myov1 (make-overlay 16 51))
(overlay-put myov2 'display "STRING2")
(overlay-put myov1 'display "STRING1")

ie if the wider overlay is applied last, it should take all.



reply via email to

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