[Top][All Lists]

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

Re: Nested display strings

From: Eli Zaretskii
Subject: Re: Nested display strings
Date: Sun, 24 Apr 2011 20:37:09 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Sun, 24 Apr 2011 02:01:34 -0300
> > 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.
> There's indeed little doubt that this is "as designed", it's probably
> just inherited from the view of char-properties as a minor variant of
> text-properties.
> The result makes some sense but AFAIK in all the cases I bumped into it
> it seemed like a bug rather than a feature.
> So I think it's OK to consider this case as "unsupported", so any
> behavior is acceptable.  Maybe the best would be to detect the situation
> and signal some kind of warning.

What about the case when the "inner" overlay has higher priority than
the "outer" one?  That is, this variant:

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

A number of people expressed their opinion that in this case, it is
desirable to show STRING1STRING2STRING1.  (I don't think it's right,
but that's me.)  If we want to support that, then we cannot simply
jump to the end of the overlay, as the simple change below does.  With
that change, we display STRING1 once, and STRING2 is not displayed at
all, irrespective of priorities.

=== modified file 'src/xdisp.c'
--- src/xdisp.c 2011-04-13 17:41:04 +0000
+++ src/xdisp.c 2011-04-24 17:26:30 +0000
@@ -790,7 +790,7 @@ static int resize_mini_window_1 (EMACS_I
 static Lisp_Object unwind_redisplay (Lisp_Object);
 static int string_char_and_length (const unsigned char *, int *);
 static struct text_pos display_prop_end (struct it *, Lisp_Object,
-                                         struct text_pos);
+                                         struct text_pos, Lisp_Object);
 static int compute_window_start_on_continuation_line (struct window *);
 static Lisp_Object safe_eval_handler (Lisp_Object);
 static void insert_left_trunc_glyphs (struct it *);
@@ -3882,18 +3882,25 @@ handle_display_prop (struct it *it)
    at START_POS in OBJECT.  */
 static struct text_pos
-display_prop_end (struct it *it, Lisp_Object object, struct text_pos start_pos)
+display_prop_end (struct it *it, Lisp_Object object, struct text_pos start_pos,
+                 Lisp_Object overlay)
   Lisp_Object end;
   struct text_pos end_pos;
-  end = Fnext_single_char_property_change (make_number (CHARPOS (start_pos)),
+  if (!NILP (overlay))
+    CHARPOS (end_pos) = OVERLAY_POSITION (OVERLAY_END (overlay));
+  else
+    {
+      end =
+       Fnext_single_char_property_change (make_number (CHARPOS (start_pos)),
                                           Qdisplay, object, Qnil);
-  CHARPOS (end_pos) = XFASTINT (end);
+      CHARPOS (end_pos) = XFASTINT (end);
+    }
   if (STRINGP (object))
     compute_string_pos (&end_pos, start_pos, it->string);
-    BYTEPOS (end_pos) = CHAR_TO_BYTE (XFASTINT (end));
+    BYTEPOS (end_pos) = CHAR_TO_BYTE (CHARPOS (end_pos));
   return end_pos;
@@ -4099,7 +4106,7 @@ handle_single_display_spec (struct it *i
   /* Characters having this form of property are not displayed, so
      we have to find the end of the property.  */
   start_pos = *position;
-  *position = display_prop_end (it, object, start_pos);
+  *position = display_prop_end (it, object, start_pos, overlay);
   value = Qnil;
   /* Stop the scan at that end position--we assume that all

reply via email to

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