before-string property has no effect if display property is empty string

before-string property has no effect if display property is empty string

[Joe Wells]

The documentation leads me to believe that the before-string and
display properties of an overlay should be orthogonal.  However, the
before-string is not displayed if the display property is the empty
string.

Reproduce by evaluating this code:

  (let ((buf (get-buffer-create "foo")))
    (with-current-buffer buf
      (display-buffer buf)
      (erase-buffer)
      (dolist (o (overlays-in (point-min) (point-max)))
        (delete-overlay o))
      (insert "ABC")
      (let ((o (make-overlay 2 3))
            (s (make-string 3 ?X)))
        (overlay-put o 'display "")
        (overlay-put o 'before-string s))))

You will see the “foo” window pop up and in the window you will see
“AC”.  I expected that instead “AXXXC” would be shown.

This seems like a bug.

Thanks for your time in considering this bug report.

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

Major mode: Lisp Interaction

Minor modes in effect:
  TeX-source-specials-mode: t
  auto-fill-function: do-auto-fill
  shell-dirtrack-mode: t
  outline-minor-mode: t
  desktop-save-mode: t
  url-handler-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-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: before-string property has no effect if display property is empty string

[Richard Stallman]

    The documentation leads me to believe that the before-string and
    display properties of an overlay should be orthogonal.  However, the
    before-string is not displayed if the display property is the empty
    string.

I think the thing to do is document this.

Does the same happen for the after-string?

Re: before-string property has no effect if display property is empty string

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>     The documentation leads me to believe that the before-string and
>     display properties of an overlay should be orthogonal.  However, the
>     before-string is not displayed if the display property is the empty
>     string.
>
> I think the thing to do is document this.

This is not clear.  For example, linum.el makes empty overlays with
before-string properties and no display property at all.  And this
works.  So why shouldn't it work when there is a display property that
is the empty string?

> Does the same happen for the after-string?

It works fine with after-string.  The following expression displays
“AXXXC” (correctly):

  (let ((buf (get-buffer-create "foo")))
    (with-current-buffer buf
      (display-buffer buf)
      (erase-buffer)
      (dolist (o (overlays-in (point-min) (point-max)))
        (delete-overlay o))
      (insert "ABC")
      (let ((o (make-overlay 2 3))
            (s (make-string 3 ?X)))
        (overlay-put o 'display "")
        (overlay-put o 'after-string s))))

Given that it works with after-string, this is evidence for
interpreting the behavior with before-string as a bug.

-- 
Joe

Re: before-string property has no effect if display property is empty string

[Richard Stallman]

    >     The documentation leads me to believe that the before-string and
    >     display properties of an overlay should be orthogonal.  However, the
    >     before-string is not displayed if the display property is the empty
    >     string.
    >
    > I think the thing to do is document this.

    This is not clear.  For example, linum.el makes empty overlays with
    before-string properties and no display property at all.  And this
    works.  So why shouldn't it work when there is a display property that
    is the empty string?

Logically it ought to work, but do we have anyone who can debug it and
fix it?  Would you like to debug it?

Re: before-string property has no effect if display property is empty string

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>     >     The documentation leads me to believe that the
>     >     before-string and display properties of an overlay should
>     >     be orthogonal.  However, the before-string is not
>     >     displayed if the display property is the empty string.
>     >
>     > I think the thing to do is document this.
>
>     This is not clear.  For example, linum.el makes empty overlays
>     with before-string properties and no display property at all.
>     And this works.  So why shouldn't it work when there is a
>     display property that is the empty string?
>
> Logically it ought to work, but do we have anyone who can debug it and
> fix it?  Would you like to debug it?

I am too busy with my job to debug it.

I don't object to documenting it as a bug (hopefully to be fixed
someday).  I think it is not the right choice to document it as the
correct behavior.

-- 
Joe

Re: before-string property has no effect if display property is empty string

[Richard Stallman]

I don't believe in "documenting bugs".  Bugs should be fixed,
not treated as permanent.

Would someone please debug this?


    The documentation leads me to believe that the before-string and
    display properties of an overlay should be orthogonal.  However, the
    before-string is not displayed if the display property is the empty
    string.

    Reproduce by evaluating this code:

      (let ((buf (get-buffer-create "foo")))
	(with-current-buffer buf
	  (display-buffer buf)
	  (erase-buffer)
	  (dolist (o (overlays-in (point-min) (point-max)))
	    (delete-overlay o))
	  (insert "ABC")
	  (let ((o (make-overlay 2 3))
		(s (make-string 3 ?X)))
	    (overlay-put o 'display "")
	    (overlay-put o 'before-string s))))

    You will see the foo window pop up and in the window you     will see
    AC.  I expected that instead AXXXC would be shown.

    > Does the same happen for the after-string?

    It works fine with after-string.