GNU bug report logs - #8177
24.0.50; `find-file' 2nd time for image file - regression

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 8177 in the body.
You can then email your comments to 8177 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: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; `find-file' 2nd time for image file - regression
Date: Sat, 5 Mar 2011 00:03:51 -0800

1. This is a regression; it works fine in Emacs 22 and Emacs 23.
 
M-: (find-file "...foo.jpg")
 
where `...foo.jpg' is an absolute file name of an image file (of a type
that is supported).  The image is displayed - no problem.  Good.
 
Now repeat it:
M-: (find-file "...foo.jpg")
 
This time you get an annoying dialog.  You should just see the image
again.  Similarly, if you hit RET on the file name in Dired - first time
is OK, second time you get sent down the rabbit hole.
 

2. In addition (but this is *not* the main point of this bug report),
the annoying dialog you get uses multiple lines of text (6!) to prompt
in the minibuffer (or in a popup, depending on how you invoke the
function) for a y-or-n answer.  The prompt text is *far* too long and
pretty much incomprehensible to an average user.  This is the `y-or-n-p'
prompt (including its line breaks):
 
"The file maybe-a-very-long-file-name.jpg is already visited literally,
meaning no coding system decoding, format conversion, or local variables.
You have asked to visit it normally,
but Emacs can only visit a file in one way at a time.
 
Do you want to revisit the file normally now? (y or n) "
 
That is _ridiculously_ long and confusing.  It is horribly user
unfriendly.  `find-file-noselect' is now filled to the gills with such
gobbledygook prompts, each more twisted and verbose than the next.
 
It's hard to believe that we have been prompting users this way since
Emacs 22 (the prompts for this are much shorter in Emacs 21).
Fortunately, these prompts not encountered very often.


In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-02-28 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
 

Message #10 received at 8177-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8177-done <at> debbugs.gnu.org
Subject: Re: bug#8177: 24.0.50;
	`find-file' 2nd time for image file - regression
Date: Sat, 05 Mar 2011 10:54:35 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sat, 5 Mar 2011 00:03:51 -0800
> Cc: 
> 
> 1. This is a regression; it works fine in Emacs 22 and Emacs 23.
>  
> M-: (find-file "...foo.jpg")
>  
> where `...foo.jpg' is an absolute file name of an image file (of a type
> that is supported).  The image is displayed - no problem.  Good.
>  
> Now repeat it:
> M-: (find-file "...foo.jpg")
>  
> This time you get an annoying dialog.  You should just see the image
> again.  Similarly, if you hit RET on the file name in Dired - first time
> is OK, second time you get sent down the rabbit hole.

My bad; fixed now.  If you want to try the change, but cannot dump
Emacs, apply the patch below, recompile files.el, and manually load
files.elc (followed by ls-lisp.elc) into Emacs.

> 2. In addition (but this is *not* the main point of this bug report),
> the annoying dialog you get uses multiple lines of text (6!) to prompt
> in the minibuffer (or in a popup, depending on how you invoke the
> function) for a y-or-n answer.  The prompt text is *far* too long and
> pretty much incomprehensible to an average user.

I didn't do anything about this part; suggest a separate bug report,
as it's unrelated.

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2011-03-05 04:11:05 +0000
+++ lisp/ChangeLog	2011-03-05 08:48:52 +0000
@@ -1,3 +1,9 @@
+2011-03-05  Eli Zaretskii  <eliz <at> gnu.org>
+
+	* files.el (find-file-noselect): Don't ask about re-visiting
+	non-literally if the file is already visited in image-mode.
+	(Bug#8177)
+
 2011-03-05  Glenn Morris  <rgm <at> gnu.org>
 
 	* eshell/esh-mode.el (eshell-kill-buffer-function): New function.

=== modified file 'lisp/files.el'
--- lisp/files.el	2011-03-03 08:10:52 +0000
+++ lisp/files.el	2011-03-05 08:48:52 +0000
@@ -1894,8 +1894,8 @@ the various files."
 			   (not nonexistent)
 			   ;; It is confusing to ask whether to visit
 			   ;; non-literally if they have the file in
-			   ;; hexl-mode.
-			   (not (eq major-mode 'hexl-mode)))
+			   ;; hexl-mode or image-mode.
+			   (not (memq major-mode '(hexl-mode image-mode))))
 		  (if (buffer-modified-p)
 		      (if (y-or-n-p
 			   (format

Message #11 received at 8177-done <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 8177-done <at> debbugs.gnu.org
Subject: RE: bug#8177: 24.0.50;
	`find-file' 2nd time for image file - regression
Date: Sat, 5 Mar 2011 07:08:54 -0800

> My bad; fixed now.

Wow, that was quick. Thank you.

> If you want to try the change, but cannot dump
> Emacs, apply the patch below, recompile files.el, and manually load
> files.elc (followed by ls-lisp.elc) into Emacs.

I'll wait until I can get another Windows binary from Sean.

> I didn't do anything about this part; suggest a separate bug report,
> as it's unrelated.

OK.

Previous Next

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