bug#47240: Images Treated as Whitespace and Removed from Buffer

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#47240: Images Treated as Whitespace and Removed from Buffer

Spaulding, Jeff

 

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

 

Reply | Threaded
Open this post in threaded view
|

bug#47240: Images Treated as Whitespace and Removed from Buffer

Stefan Kangas
Lars Ingebrigtsen <[hidden email]> writes:

> "Spaulding, Jeff" <[hidden email]> 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?



Reply | Threaded
Open this post in threaded view
|

bug#47240: Images Treated as Whitespace and Removed from Buffer

Spaulding, Jeff
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:[hidden email]]
Sent: Saturday, April 3, 2021 7:30 PM
To: Lars Ingebrigtsen
Cc: Spaulding, Jeff; [hidden email]
Subject: Re: bug#47240: Images Treated as Whitespace and Removed from Buffer

Lars Ingebrigtsen <[hidden email]> writes:

> "Spaulding, Jeff" <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

bug#47240: Images Treated as Whitespace and Removed from Buffer

Lars Ingebrigtsen
In reply to this post by Stefan Kangas
Stefan Kangas <[hidden email]> 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