GNU bug report logs - #47240
Images Treated as Whitespace and Removed from Buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47240 in the body.
You can then email your comments to 47240 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Spaulding, Jeff" <jeff.spaulding <at> englobal.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Images Treated as Whitespace and Removed from Buffer
Date: Thu, 18 Mar 2021 01:04:18 +0000

[Message part 1 (text/plain, inline)]

Have a test image ready as "test.png" (the format is irrelevant, tested
with both PNG and SVG).

Start Emacs using emacs -Q

Press C-b and enter a new buffer name to get a Fundamental mode buffer.

Press M-: to bring up an Eval: prompt in the minibuffer.  Enter the
following elisp code:

(insert-image (create-image "test.png"))

The image will appear in the buffer.

Press Enter.  The image will disappear.

The image seems to always be deleted if the enter key is pressed (bound
to the newline function), but not when C-j is pressed (bound to the
electric-newline-and-maybe-indent function).  The image will not be
deleted if there is any text following it on the line.  This suggests
the image is being treated as trailing whitespace, as trailing
whitespace is treated in the same way.

Workaround: Specifying a non-whitespace string to the create-image
function seems to mitigate this behavior.

Expectation: images don't get deleted automatically.

This has a very unfortunate collision with aggressive-indent-mode, which
makes it so that when you eval elisp in the *scratch* buffer the image
appears and disappears immediately.

I did not find anything in the Emacs manual about images, and the Images
section of the elisp manual does not mention it anywhere obvious.  It
took quite a bit of tracking down before I realized that it was the
trailing whitespace removal that was causing the problem, and that
specifying a string to create-image would negate the whitespace-removal
functionality.

If this behavior was documented (perhaps in the create-image docstring)
it would have saved much confusion.  It would still be nice if images
survived whitespace pruning by default, though.


In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
of 2020-08-12 built on LT3AV7KMK
Windowing system distributor 'The Cygwin/X Project', version 11.0.12001000
System Description: Debian GNU/Linux 10 (buster)

Recent messages:
funcall-interactively: End of buffer
Type C-x 1 to delete the help window, C-M-v to scroll help.

<pause> is undefined [2 times]
Entering debugger...
<pause> is undefined
Back to top level
t
previous-line: Beginning of buffer [8 times]
<pause> is undefined

Configured using:
'configure --prefix=/usr/local --with-x --with-x-toolkit=lucid
--with-sound=no --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO DBUS GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cl-print debug
backtrace find-func cl-extra seq byte-opt gv bytecomp byte-compile cconv
help-fns radix-tree help-mode easymenu time-date subr-x cl-loaddefs
cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 49840 9658)
(symbols 48 6446 1)
(strings 32 17803 1913)
(string-bytes 1 566544)
(vectors 16 10258)
(vector-slots 8 134777 11958)
(floats 8 37 36)
(intervals 56 256 8)
(buffers 1000 14))

[Message part 2 (text/html, inline)]

Message #8 received at 47240 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Spaulding, Jeff" <jeff.spaulding <at> englobal.com>
Cc: 47240 <at> debbugs.gnu.org
Subject: Re: bug#47240: Images Treated as Whitespace and Removed from Buffer
Date: Fri, 19 Mar 2021 09:45:35 +0100

"Spaulding, Jeff" <jeff.spaulding <at> englobal.com> writes:

> Press M-: to bring up an Eval: prompt in the minibuffer.  Enter the
> following elisp code:
>
> (insert-image (create-image "test.png"))
>
> The image will appear in the buffer.
>
> Press Enter.  The image will disappear.
>
> The image seems to always be deleted if the enter key is pressed (bound
> to the newline function), but not when C-j is pressed (bound to the
> electric-newline-and-maybe-indent function).  The image will not be
> deleted if there is any text following it on the line.  This suggests
> the image is being treated as trailing whitespace, as trailing
> whitespace is treated in the same way.

I think this is working basically as designed.  By default, images are
whitespace and handled as such, but if you don't want that, you have to
say

(insert-image (create-image "test.png") "*")

or something like that.

So I'm not sure whether there's anything to fix here.  Does anybody else
have an opinion here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 47240 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47240 <at> debbugs.gnu.org, "Spaulding, Jeff" <jeff.spaulding <at> englobal.com>
Subject: Re: bug#47240: Images Treated as Whitespace and Removed from Buffer
Date: Sat, 3 Apr 2021 19:30:07 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "Spaulding, Jeff" <jeff.spaulding <at> englobal.com> writes:
>
>> Press M-: to bring up an Eval: prompt in the minibuffer.  Enter the
>> following elisp code:
>>
>> (insert-image (create-image "test.png"))
>>
>> The image will appear in the buffer.
>>
>> Press Enter.  The image will disappear.
>>
>> The image seems to always be deleted if the enter key is pressed (bound
>> to the newline function), but not when C-j is pressed (bound to the
>> electric-newline-and-maybe-indent function).  The image will not be
>> deleted if there is any text following it on the line.  This suggests
>> the image is being treated as trailing whitespace, as trailing
>> whitespace is treated in the same way.
>
> I think this is working basically as designed.  By default, images are
> whitespace and handled as such, but if you don't want that, you have to
> say
>
> (insert-image (create-image "test.png") "*")
>
> or something like that.
>
> So I'm not sure whether there's anything to fix here.  Does anybody else
> have an opinion here?

I agree that it seems to works as documented.

Perhaps the docstring of `insert-image' could make this caveat more
clear though?

Message #16 received at 47240 <at> debbugs.gnu.org (full text, mbox):

From: "Spaulding, Jeff" <jeff.spaulding <at> englobal.com>
To: Stefan Kangas <stefan <at> marxist.se>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "47240 <at> debbugs.gnu.org" <47240 <at> debbugs.gnu.org>
Subject: RE: bug#47240: Images Treated as Whitespace and Removed from Buffer
Date: Sun, 4 Apr 2021 00:37:37 +0000

Assuming that images being treated as whitespace is the intended behavior (which I think is odd, but I can accept), I feel that a documentation change would be sufficient.

I was surprised by the fact that images were treated as whitespace.  It doesn't seem intuitive that an image would be treated the same as an invisible piece of text.

Documenting this would prevent others from having to go through the confusion I did, however.

-----Original Message-----
From: Stefan Kangas [mailto:stefan <at> marxist.se] 
Sent: Saturday, April 3, 2021 7:30 PM
To: Lars Ingebrigtsen
Cc: Spaulding, Jeff; 47240 <at> debbugs.gnu.org
Subject: Re: bug#47240: Images Treated as Whitespace and Removed from Buffer

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "Spaulding, Jeff" <jeff.spaulding <at> englobal.com> writes:
>
>> Press M-: to bring up an Eval: prompt in the minibuffer.  Enter the 
>> following elisp code:
>>
>> (insert-image (create-image "test.png"))
>>
>> The image will appear in the buffer.
>>
>> Press Enter.  The image will disappear.
>>
>> The image seems to always be deleted if the enter key is pressed 
>> (bound to the newline function), but not when C-j is pressed (bound 
>> to the electric-newline-and-maybe-indent function).  The image will 
>> not be deleted if there is any text following it on the line.  This 
>> suggests the image is being treated as trailing whitespace, as 
>> trailing whitespace is treated in the same way.
>
> I think this is working basically as designed.  By default, images are 
> whitespace and handled as such, but if you don't want that, you have 
> to say
>
> (insert-image (create-image "test.png") "*")
>
> or something like that.
>
> So I'm not sure whether there's anything to fix here.  Does anybody 
> else have an opinion here?

I agree that it seems to works as documented.

Perhaps the docstring of `insert-image' could make this caveat more clear though?

Message #19 received at 47240 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 47240 <at> debbugs.gnu.org, "Spaulding, Jeff" <jeff.spaulding <at> englobal.com>
Subject: Re: bug#47240: Images Treated as Whitespace and Removed from Buffer
Date: Sun, 04 Apr 2021 21:48:05 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Perhaps the docstring of `insert-image' could make this caveat more
> clear though?

Yup; I've now clarified this in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.