GNU bug report logs -
#16062
24.3; Missing .png file gives poor error message when opened
Previous Next
Reported by: Alex Willisson <atw <at> mit.edu>
Date: Thu, 5 Dec 2013 21:32:02 UTC
Severity: minor
Tags: fixed
Found in version 24.3
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16062 in the body.
You can then email your comments to 16062 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Thu, 05 Dec 2013 21:32:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alex Willisson <atw <at> mit.edu>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 05 Dec 2013 21:32:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Fri, 06 Dec 2013 07:20:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16062 <at> debbugs.gnu.org (full text, mbox):
> From: Alex Willisson <atw <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Fri, 06 Dec 2013 07:58:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Fri, 06 Dec 2013 08:40:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 16062 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 06 Dec 2013 08:57:04 +0100
> From: Jarek Czekalski <jarekczek <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Fri, 06 Dec 2013 21:05:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 16062 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Sat, 07 Dec 2013 07:28:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 16062 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 06 Dec 2013 22:05:17 +0100
> From: Jarek Czekalski <jarekczek <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Fri, 13 Dec 2013 21:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 16062 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Sat, 14 Dec 2013 06:52:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 16062 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> jurta.org>
> Cc: Jarek Czekalski <jarekczek <at> poczta.onet.pl>, 16062 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Thu, 20 Aug 2020 18:11:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 16062 <at> debbugs.gnu.org (full text, mbox):
Alex Willisson <atw <at> 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
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 20 Aug 2020 18:12:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
16062 <at> debbugs.gnu.org and Alex Willisson <atw <at> mit.edu>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 20 Aug 2020 18:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Thu, 20 Aug 2020 18:31:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 16062 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 20 Aug 2020 20:10:45 +0200
> Cc: 16062 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16062
; Package
emacs
.
(Thu, 20 Aug 2020 18:40:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 16062 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 18 Sep 2020 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 220 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.