bug#16062: 24.3; Missing .png file gives poor error message when opened

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Alex Willisson]

When I try to open a .png file which does not exist, I get the error
message "Cannot display image: (Cannot determine image type)" in the
minibuffer, instead of something more related to "File does not exist"

Steps for reproduction:

$ emacs -Q

C-x C-f not_an_actual_file.png <return>

This bug looks like it occurs for nearly all image extensions, I have
reproduced it with these extensions: .png, .gif, .jpeg, .jpg, .ppm,
.pnm, .tiff, .xpm, .xcf, .psd, .bmp, .tga, .ico, .rgb, and .svg.

In GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.9.10)
 of 2013-08-14 on buildvm-17.phx2.fedoraproject.org
Windowing system distributor `Fedora Project', version 11.0.11402000
System Description:    Fedora release 20 (Heisenbug)

Configured using:
 `configure '--build=x86_64-redhat-linux-gnu'
 '--host=x86_64-redhat-linux-gnu' '--program-prefix='
 '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
 '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
 '--datadir=/usr/share' '--includedir=/usr/include'
 '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
 '--localstatedir=/var' '--sharedstatedir=/var/lib'
 '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus'
 '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
 '--with-xft' '--with-xpm' '--with-x-toolkit=gtk3' '--with-gpm=no'
 'build_alias=x86_64-redhat-linux-gnu'
 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
 -fstack-protector-strong --param=ssp-buffer-size=4
 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ''

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-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

Recent input:
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
Loading /usr/share/emacs/site-lisp/site-start.d/desktop-entry-mode-init.el
(source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/rpmdev-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/systemtap-init.el
(source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs gv format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils actionscript-mode cl cl-lib
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Eli Zaretskii]

> From: Alex Willisson <atw@mit.edu>
> Date: Thu, 5 Dec 2013 16:27:35 -0500
> 
> When I try to open a .png file which does not exist, I get the error
> message "Cannot display image: (Cannot determine image type)" in the
> minibuffer, instead of something more related to "File does not exist"
> 
> Steps for reproduction:
> 
> $ emacs -Q
> 
> C-x C-f not_an_actual_file.png <return>

How should Emacs know whether you intend to visit an existing file or
create a new one?

bug#16062: [SPAM] bug#16062: 24.3; Missing .png file gives poor error message when opened

[Jarek Czekalski]

W dniu 2013-12-06 08:18, Eli Zaretskii pisze:
> How should Emacs know whether you intend to visit an existing file or
> create a new one?

It seems so easy to determine what is the intention of visiting a png 
file. But if Emacs admin does not know that, then I assume I make some 
silly newbie mistake and it is in fact impossible.

Jarek

bug#16062: [SPAM] bug#16062: 24.3; Missing .png file gives poor error message when opened

[Eli Zaretskii]

> Date: Fri, 06 Dec 2013 08:57:04 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> 
> W dniu 2013-12-06 08:18, Eli Zaretskii pisze:
> > How should Emacs know whether you intend to visit an existing file or
> > create a new one?
> 
> It seems so easy to determine what is the intention of visiting a png 
> file.

Is it?  What if I come up with an Emacs mode that lets users _create_
PNG files?

> But if Emacs admin does not know that, then I assume I make some 
> silly newbie mistake and it is in fact impossible.

I didn't ask the (slightly provocative) question to indicate that I
consider your request silly.  I asked it to put the issue in
perspective.  I agree it would be good to make the error message more
clear in this case, I just suggest that we think about the possible
alternatives to "File does not exist", because we don't show such a
message when users visit non-existent files.

IOW, I submit that the problem is with image-mode throwing an error in
this case, instead of showing "(New file)" in the echo area, just like
we do with any non-existing file.  We could also turn image-mode off
in such a case, although the correctness of that is less clear to me.

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Jarek Czekalski]

W dniu 12/06/2013 09:38 AM, Eli Zaretskii pisze:
> Is it?  What if I come up with an Emacs mode that lets users _create_
> PNG files?

What I actually had in mind was that Emacs already does this guessing 
(what was the intention of opening a png file) and we don't want to 
change this process. But after we decided we want to display the 
graphics and before passing the filename to the graphic library, we 
should check if file exists.

If file does not exist - give the exact message or fallback to 
non-graphical mode. Both solutions would make it obvious, that the file 
does not exists. I guess that's the intention of Alex, who reported this.

Thanks
Jarek

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Eli Zaretskii]

> Date: Fri, 06 Dec 2013 22:05:17 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> 
> W dniu 12/06/2013 09:38 AM, Eli Zaretskii pisze:
> > Is it?  What if I come up with an Emacs mode that lets users _create_
> > PNG files?
> 
> What I actually had in mind was that Emacs already does this guessing 
> (what was the intention of opening a png file) and we don't want to 
> change this process. But after we decided we want to display the 
> graphics and before passing the filename to the graphic library, we 
> should check if file exists.

That's not how "C-x C-f" works in this case.  It visits the file as
usual, and then turns on image-mode, which instructs the image library
to display the image using the data we already have in the buffer.  So
the file name is never passed to the image library.

IOW, Emacs does the same in this case as when you type

  C-x C-f non-existent-file.c RET

In the latter case, you get an empty buffer that is in CC mode, and a
message "(New file)" in the echo area.

Therefore, I submit that the problem is with image-mode, which barfs
on empty buffers, obviously assuming such situations won't happen.

> If file does not exist - give the exact message or fallback to 
> non-graphical mode. Both solutions would make it obvious, that the file 
> does not exists. I guess that's the intention of Alex, who reported this.

Would it be wrong to have an empty buffer put in image-mode and "(New
file)" displayed in the echo area?  That is how Emacs behaves in any
other case when the user visits a file that does not exist.

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Juri Linkov]

> IOW, Emacs does the same in this case as when you type
>
>   C-x C-f non-existent-file.c RET
>
> In the latter case, you get an empty buffer that is in CC mode, and a
> message "(New file)" in the echo area.

In this case the echo area displays "Loading cc-langs...done",
but not "(New file)".

If we'll remove the message "Cannot display image: (Cannot
determine image type)" from image-mode.el, then it still will
display "Type C-c C-c to view the image as an image.",
but not "(New file)" (but it's still visible in the *Messages* buffer).

So the problem of overridden messages is general.  A possible solution
is to collect a batch of the latest messages and display them in the
multi-line echo area.

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Jarek Czekalski <jarekczek@poczta.onet.pl>,  16062@debbugs.gnu.org
> Date: Fri, 13 Dec 2013 23:58:03 +0200
> 
> > IOW, Emacs does the same in this case as when you type
> >
> >   C-x C-f non-existent-file.c RET
> >
> > In the latter case, you get an empty buffer that is in CC mode, and a
> > message "(New file)" in the echo area.
> 
> In this case the echo area displays "Loading cc-langs...done",
> but not "(New file)".
> 
> If we'll remove the message "Cannot display image: (Cannot
> determine image type)" from image-mode.el, then it still will
> display "Type C-c C-c to view the image as an image.",
> but not "(New file)" (but it's still visible in the *Messages* buffer).
> 
> So the problem of overridden messages is general.  A possible solution
> is to collect a batch of the latest messages and display them in the
> multi-line echo area.

Or maybe image-mode could display another "(New file)" when it
discovers that the buffer is empty.

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Lars Ingebrigtsen]

Alex Willisson <atw@mit.edu> writes:

> When I try to open a .png file which does not exist, I get the error
> message "Cannot display image: (Cannot determine image type)" in the
> minibuffer, instead of something more related to "File does not exist"
>
> Steps for reproduction:
>
> $ emacs -Q
>
> C-x C-f not_an_actual_file.png <return>

I've now fixed this for Emacs 28 -- it now says there's no image data
present instead of the confusing error message about image types.

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

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 20 Aug 2020 20:10:45 +0200
> Cc: 16062@debbugs.gnu.org
> 
> > $ emacs -Q
> >
> > C-x C-f not_an_actual_file.png <return>
> 
> I've now fixed this for Emacs 28 -- it now says there's no image data
> present

It does?  On my system, it just says "New file".  Which is not bad,
but doesn't match your description.

bug#16062: 24.3; Missing .png file gives poor error message when opened

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I've now fixed this for Emacs 28 -- it now says there's no image data
>> present
>
> It does?  On my system, it just says "New file".  Which is not bad,
> but doesn't match your description.

It does if the file exists (but is empty).

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