Subject: Re: redisplay bugs

From: Glenn Morris <[email-masked]>
Date: Tue, 21 Oct 2008 21:43:32 -0400

I am closing this extremely confusing (to me) uber-bug. I have opened
separate reports for the outstanding issues.

> 1. Faces on a display property on a before-string behave differently
>    depending on where the display property is in the before-string.
>    For a display property at the beginning of the before-string, its
>    face is used and the before-string's face is ignored (I think this
>    is correct).  For a display property not at the beginning of the
>    before-string, its face is completely ignored, and the face of the
>    before-string is used instead.

As mentioned before, this seems fixed. Here is a simpler test-case
(which still looks crazy to me...):

(let ((buff (generate-new-buffer "overlay test"))
      o)
  (with-current-buffer buff
    (insert "text")
    (setq o (make-overlay (point-min) (point-max)))
    (overlay-put o 'display "display")
    (overlay-put o 'before-string
                 (concat
                  (propertize "before-"
                              'face '(:background "green")
                              'display
                              (propertize "BEFORE-" 'face '(:background "red")))
                  (propertize "string"
                              'face '(:background "yellow")
                              'display
                              (propertize "STRING" 'face '(:background "blue")))))
    (pop-to-buffer buff)))

One sees "BEFORE-" with a red background and "STRING" with a blue background.

> 2. When a substring of a before-string beginning at offset O has a
>    display property which is a string S, the first O characters of S
>    are not displayed.  If S is not at least O+1 characters long, then
>    disastrous things start to happen.

I have difficulty understanding this ("the first 0 characters" are not
displayed?), but as I said before it seems to be fixed.

> 3. The before-string somehow inherits face attributes from the face
> of the character that follows the start of the overlay.

It seems I was mistaken before, this still occurs. Opened as bug#1222.

> 4. The display property of an overlay somehow inherits face
> attributes from the face of the character that follows the start of
> the overlay.

Opened as bug#1222.

> 5. The help-echo and mouse-face properties of an overlay with both a
>    before-string and a display property only affect the material
>    displayed by the overlay's display property.

Opened as bugs #1220 and #1221.

> The exception is that the overlay's mouse-face property does
> correctly cover both the overlays display and after-string
> properties.

Mentioned in bug #1220.

> Strangely, the after-string also inherits face attributes from the
> character after the beginning of the overlay, not the character just
> before the _end_ of the overlay.

Mentioned in bug#1222.

>>> Can someone write a patch so that the overlay's face property (and
>>> other display-related properties) won't apply to its before-string?

In Emacs 22.2 and up, overlay faces no longer apply to the before- and
after- strings. They still affect the display part, which seems
reasonable to me.

Example:

(let ((buff (generate-new-buffer "overlay test"))
      o)
  (with-current-buffer buff
    (insert "text")
    (setq o (make-overlay (point-min) (point-max)))
    (overlay-put o 'display "display")
    (overlay-put o 'face '(:background "blue"))
    (overlay-put o 'before-string "before")
    (overlay-put o 'after-string "after")
    (pop-to-buffer buff)))

Only "display" has a blue background in 22.2 and up.

This was also discussed on emacs-devel:

http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01360.html

> Redisplay goes horribly wrong when a before-string contains multiple
> display properties.

As mentioned before, this is fixed.