overlay face property not used for after-string property

overlay face property not used for after-string property

[Joe Wells]

BUG:  An overlay's face property is applied to its before-string
and display properties, but not to its after-string property.

Reproduce with this expression (see below for definition of
test-in-fresh-buffer-and-window):

  (test-in-fresh-buffer-and-window
   (insert "123")
   (let ((o (make-overlay 2 3)))
     (overlay-put o 'before-string "B")
     (overlay-put o 'after-string "A")
     (overlay-put o 'display "D")
     (overlay-put o 'face 'highlight)))

This displays “1BDA3”.  The “BDA” portion should be displayed
with face “highlight”, which means that the background should be
colored “darkseagreen2”.  However, only the “BD” portion is
displayed with face “highlight” and the “A” portion is wrongly
not displayed with any special face.

I'm assuming the following macro definition in my reproduction
code above:

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

I hope this bug report is 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: overlay face property not used for after-string property

[Chong Yidong]

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

> BUG: An overlay's face property is applied to its before-string
> and display properties, but not to its after-string property.

Sorry for the delay; I just got the time to look at this in detail.

Currently, Emacs uses the `face' property for the display property, but
not the before-string and after-string properties.  This is a rather
ambiguous corner case for the interaction of different overlay
properties, and my inclination is to leave it alone.  If you wish to
change the face of either one of these strings, you can add the `face'
text property to the string, and this will be displayed correctly.

Does anyone have any objection?  If not, I'll shortly update the elisp
manual to clarify this issue.

Re: overlay face property not used for after-string property

[martin rudalics]

 > Currently, Emacs uses the `face' property for the display property, but
 > not the before-string and after-string properties.  This is a rather
 > ambiguous corner case for the interaction of different overlay
 > properties, and my inclination is to leave it alone.  If you wish to
 > change the face of either one of these strings, you can add the `face'
 > text property to the string, and this will be displayed correctly.
 >
 > Does anyone have any objection?  If not, I'll shortly update the elisp
 > manual to clarify this issue.

No objections, but could you please look into the diverging behaviors of
Emacs 22 and 23 wrt

http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01961.html

The behavior of my Emacs 22 is wrong here - but this may have been
already fixed for Emacs 22.2 ;-)