two display bugs involving interactions between after-string and display properties of adjacent overlays

two display bugs involving interactions between after-string and display properties of adjacent overlays

[Joe Wells]

Here are two more display bugs I found while trying to improve the
code in tex-fold.el in AUCTeX.

These bugs involve interactions between after-string and display
properties of adjacent overlays.

I'm assuming this macro in my reproduction code below:

  (defmacro test-in-fresh-buffer-and-window (&rest body)
    `(progn
       (delete-other-windows)
       (kill-buffer (get-buffer-create "xyzzy"))
       (let ((xyzzy-buf (get-buffer-create "xyzzy")))
         (set-buffer xyzzy-buf)
         (display-buffer xyzzy-buf)
         ,@body
         )))

BUG #1:  An overlay's after-string property that would appear at the
end of the buffer is not displayed, if the same overlay also has a
display property and an immediately preceding overlay also has an
after-string property.  (Putting extra characters at the end of the
buffer works around this bug.)

Reproduce with this expression:

  (test-in-fresh-buffer-and-window
   (insert "AB")
   (let ((o1 (make-overlay 1 2))
         (o2 (make-overlay 2 3)))
     (overlay-put o1 'after-string "1")
     (overlay-put o2 'after-string "2")
     (overlay-put o2 'display "b")
     ))

The above expression should display “A1b2”.
The above expression wrongly actually displays “A1b”.

BUG #2:  An overlay's display property and after-string property are
not displayed if an immediately following overlay shares the same Lisp
string as its display property.  (Using two distinct display strings
with identical contents works around the bug.)

Reproduce with this expression:

  (test-in-fresh-buffer-and-window
   (insert "ABCD")
   (let ((o1 (make-overlay 2 3))
         (o2 (make-overlay 3 4))
         (s #1=" "))
     (overlay-put o1 'after-string "1")
     (overlay-put o1 'display #1#)
     (overlay-put o2 'display #1#)))

The above expression should display “A 1 D”.
The above expression wrongly actually displays “A D”.

I hope these bug reports are helpful.

Joe

======================================================================
In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-06-27 on artemis
Windowing system distributor `The X.Org Foundation', version 11.0.70000000
configured using `configure  '--prefix=/home/jbw/local2' '--enable-debug' '--disable-nls' '--with-x-toolkit=gtk' 'CFLAGS=-O0 -g3 -ggdb''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: jbw
  value of $LANG: nil
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Minor modes in effect:
  TeX-source-specials-mode: t
  outline-minor-mode: t
  desktop-save-mode: t
  url-handler-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  size-indication-mode: t
  line-number-mode: t
  transient-mark-mode: t

Re: two display bugs involving interactions between after-string and display properties of adjacent overlays

[Joe Wells]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> Here are two more display bugs I found while trying to improve the
> code in tex-fold.el in AUCTeX.

Here is a third such bug.

> These bugs involve interactions between after-string and display
> properties of adjacent overlays.

Ditto.

> I'm assuming this macro in my reproduction code below:
>
>   (defmacro test-in-fresh-buffer-and-window (&rest body)
>     `(progn
>        (delete-other-windows)
>        (kill-buffer (get-buffer-create "xyzzy"))
>        (let ((xyzzy-buf (get-buffer-create "xyzzy")))
>          (set-buffer xyzzy-buf)
>          (display-buffer xyzzy-buf)
>          ,@body
>          )))

Ditto.

> BUG #1:  ...

> BUG #2:  ...

BUG #3:  An overlay's after-string property is not displayed if an
immediately following overlay has the empty string as its display
property.

Reproduce with this expression:

  (test-in-fresh-buffer-and-window
   (insert "ABCD")
   (let ((o1 (make-overlay 2 3))
         (o2 (make-overlay 3 4)))
     (overlay-put o1 'after-string "1")
     (overlay-put o2 'display "")))

The above expression should display “AB1D”.
The above expression wrongly actually displays “ABD”.

> ======================================================================
> In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) ...

Same details as in last message.

I hope this bug report is helpful.

-- 
Joe

Re: two display bugs involving interactions between after-string and display properties of adjacent overlays

[Chong Yidong]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> BUG #1:  An overlay's after-string property that would appear at the
> end of the buffer is not displayed, if the same overlay also has a
> display property and an immediately preceding overlay also has an
> after-string property.  (Putting extra characters at the end of the
> buffer works around this bug.)

I've checked in a fix into the trunk.  Thanks for the report.

I'm still working on the other.

Re: two display bugs involving interactions between after-string and display properties of adjacent overlays

[Chong Yidong]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> BUG #2:  An overlay's display property and after-string property are
> not displayed if an immediately following overlay shares the same Lisp
> string as its display property.  (Using two distinct display strings
> with identical contents works around the bug.)
>
> Reproduce with this expression:
>
>   (test-in-fresh-buffer-and-window
>    (insert "ABCD")
>    (let ((o1 (make-overlay 2 3))
>          (o2 (make-overlay 3 4))
>          (s #1=" "))
>      (overlay-put o1 'after-string "1")
>      (overlay-put o1 'display #1#)
>      (overlay-put o2 'display #1#)))
>
> The above expression should display “A 1 D”.
> The above expression wrongly actually displays “A D”.

This occurs because, as stated in the Emacs Lisp manual, all
consecutive characters that have the same Lisp object as their
`display' property are replaced as a single unit.  In this case, it's
somewhat ambiguous what the behavior should be, but after looking at
the code I think the behavior you suggest would be much more difficult
to implement (and slower) than the current behavior.

Furthermore, you can trivially obtain the behavior you want by making
a copy of the string using copy-sequence, so that the two display
strings are different Lisp objects.

Therefore, let's leave this alone.

Thanks for the report, however.