GNU bug report logs -
#12935
24.3.50; `load-file' handling of "el[c]" extension
Previous Next
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.
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):
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):
> 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):
> 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.