GNU bug report logs - #12935
24.3.50; `load-file' handling of "el[c]" extension

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Mon, 19 Nov 2012 17:32:01 UTC

Severity: normal

Found in version 24.3.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

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 12935 in the body.
You can then email your comments to 12935 AT debbugs.gnu.org in the normal way.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#12935; Package emacs. (Mon, 19 Nov 2012 17:32:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 19 Nov 2012 17:32:02 GMT) Full text and rfc822 format available.

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.3.50; `load-file' handling of "el[c]" extension
Date: Mon, 19 Nov 2012 09:30:39 -0800
Perhaps an enhancement request.  But if there is a good reason not to do
this then please close the request.  IOW, more of a question than an
outright request.
 
In Emacs 20, this is the behavior for `load-file'.  I have a library
icicles-cmd1.el, which requires library icicles-mac.el[c].  I do this:
 
M-x load-file RET icicles-cmd1 RET
 
Emacs offers this:
 
Load file: c:/the-dir/icicles-cmd1.el [Confirm]
 
I hit RET.  Emacs says this: Cannot open load file: icicles-mac.
 
That behavior seems helpful to me.  And if I do this in `the-dir':
 
M-: (add-to-list 'load-path ".") ; then this is the interaction:
 
M-x load-file RET icicles-cmd1 RET
Emacs offers this:
Load file: c:/the-dir/icicles-cmd1.el [Confirm]
I hit RET.  Emacs loads icicles-mac.el[c] and then icicles-cmd1.el.
 
This behavior all seems good, to me.
 
Contrast that with Emacs 22 and later (I did not check 21):
 
M-x load-file RET icicles-cmd1
 
Emacs says this immediately: Cannot open load file: icicles-cmd1.
IOW, it does not try for icicles-cmd1.el, asking for confirmation.
 
Then:
M-: (add-to-list 'load-path ".")
M-x load-file RET icicles-cmd1 RET
 
Emacs still says only: Cannot open load file: icicles-cmd1.
 
Not very helpful.  Would you agree that this could be improved, and that
the Emacs 20 behavior in this regard is better?
 
Yes, I am aware that the doc (even for Emacs 20) says that `load-file'
does not take `load-path' into account.  I am not claiming that the
behavior is a bug.  I am asking whether it is as good as it could be.
 
And the handling of `load-path' can be separated from the intial
completion and asking for confirmation of the .el file.  That by
itself seems like an improvement.
 
Perhaps there is a downside to the Emacs 20 behavior that I'm not
seeing, looking narrowly at only this one scenario.
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-05 on
 MS-W7-DANI Bzr revision: 110809
 lekktu <at> gmail.com-20121105172930-a5gn0bwi4lndchhw Windowing system
 distributor `Microsoft Corp.', version 5.1.2600 Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src
 -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5
 -I../../libs/giflib-4.1.4-1-lib/include
 -I../../libs/jpeg-6b-4-lib/include
 -I../../libs/tiff-3.8.2-1-lib/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/gnutls-3.0.9-w32-bin/include
 -I../../libs/libiconv-1.9.2-1-lib/include'
 





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12935; Package emacs. (Mon, 19 Nov 2012 18:30:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12935 <at> debbugs.gnu.org
Subject: Re: bug#12935: 24.3.50; `load-file' handling of "el[c]" extension
Date: Mon, 19 Nov 2012 13:28:46 -0500
> Contrast that with Emacs 22 and later (I did not check 21):
> M-x load-file RET icicles-cmd1

You forgot RET at the end.

> Emacs says this immediately: Cannot open load file: icicles-cmd1.
> IOW, it does not try for icicles-cmd1.el, asking for confirmation.
 
Right, that's a bug introduced in Emacs-21.
I installed the patch below in `trunk', which should revert to the
Emacs-20 behavior.


        Stefan


=== modified file 'lisp/files.el'
--- lisp/files.el	2012-11-08 19:50:08 +0000
+++ lisp/files.el	2012-11-19 18:24:40 +0000
@@ -730,7 +730,7 @@
   ;; This is a case where .elc makes a lot of sense.
   (interactive (list (let ((completion-ignored-extensions
 			    (remove ".elc" completion-ignored-extensions)))
-		       (read-file-name "Load file: "))))
+		       (read-file-name "Load file: " nil nil 'lambda))))
   (load (expand-file-name file) nil nil t))
 
 (defun locate-file (filename path &optional suffixes predicate)





bug closed, send any further explanations to 12935 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com> Request was from Stefan Monnier <monnier <at> iro.umontreal.ca> to control <at> debbugs.gnu.org. (Mon, 19 Nov 2012 18:31:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12935; Package emacs. (Mon, 19 Nov 2012 18:34:01 GMT) Full text and rfc822 format available.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 12935 <at> debbugs.gnu.org
Subject: RE: bug#12935: 24.3.50; `load-file' handling of "el[c]" extension
Date: Mon, 19 Nov 2012 10:32:33 -0800
> Right, that's a bug introduced in Emacs-21.
> I installed the patch below in `trunk', which should revert to the
> Emacs-20 behavior.

Wow, that was quick.  Thx.  I wasn't sure it would be considered a bug,
especially since it has been thus broken for so long.





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 18 Dec 2012 12:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 12 years and 271 days ago.

Previous Next


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