GNU bug report logs -
#33901
26.1; cl-letf is unexpectedly not autoloaded
Previous Next
Reported by: Markus Triska <triska <at> metalevel.at>
Date: Sat, 29 Dec 2018 10:34:01 UTC
Severity: normal
Found in version 26.1
Done: Glenn Morris <rgm <at> gnu.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 33901 in the body.
You can then email your comments to 33901 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#33901
; Package
emacs
.
(Sat, 29 Dec 2018 10:34:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Markus Triska <triska <at> metalevel.at>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 29 Dec 2018 10:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When I invoke Emacs via:
$ emacs -Q --eval '(cl-letf ((x t)) x)'
then it displays:
eval: Symbol’s function definition is void: cl-letf
However, the documentation of cl-letf states:
"cl-letf is an autoloaded Lisp macro ... "
Hence, I expect cl-letf to be autoloaded in that case. Could this be
changed to work? Thank you!
In GNU Emacs 26.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars)
of 2018-09-22 built on mt-mbpro
Windowing system distributor 'The X.Org Foundation', version 11.0.11502000
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33901
; Package
emacs
.
(Sat, 29 Dec 2018 11:01:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 33901 <at> debbugs.gnu.org (full text, mbox):
On Dez 29 2018, Markus Triska <triska <at> metalevel.at> wrote:
> When I invoke Emacs via:
>
> $ emacs -Q --eval '(cl-letf ((x t)) x)'
>
> then it displays:
>
> eval: Symbol’s function definition is void: cl-letf
>
> However, the documentation of cl-letf states:
>
> "cl-letf is an autoloaded Lisp macro ... "
Those autoloads are only defined in the cl-macs package. You need to
load it first.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33901
; Package
emacs
.
(Sat, 29 Dec 2018 11:51:01 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> Those autoloads are only defined in the cl-macs package. You need to
> load it first.
Is this really the intended way? I mean, why is this described as an
"autoloaded" macro then? From the manual, I gather:
The “autoload” feature allows you to call a function or macro whose
function definition has not yet been loaded into Emacs. It specifies
which file contains the definition. When an autoload object appears as
a symbol’s function definition, calling that symbol as a function
automatically loads the specified file; then it calls the real ...
If I have to load cl-macs before using cl-letf, it seems to be as good
as not having an autoload for it at all. Is there any advantage to this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33901
; Package
emacs
.
(Sat, 29 Dec 2018 13:10:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 33901 <at> debbugs.gnu.org (full text, mbox):
On Dez 29 2018, Markus Triska <triska <at> metalevel.at> wrote:
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
>
>> Those autoloads are only defined in the cl-macs package. You need to
>> load it first.
Replace "cl-macs" by "cl" above, which is what defines the autoloads.
> Is this really the intended way? I mean, why is this described as an
> "autoloaded" macro then?
Because you have loaded the cl package.
> If I have to load cl-macs before using cl-letf, it seems to be as good
> as not having an autoload for it at all. Is there any advantage to this?
The cl package exists of several files. The autoloads arrange for
loading only the subset that is actually used.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33901
; Package
emacs
.
(Sun, 30 Dec 2018 10:23:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 33901 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
>> Is this really the intended way? I mean, why is this described as an
>> "autoloaded" macro then?
>
> Because you have loaded the cl package.
To be absolutely honest, for a macro that is documented as autoloaded, I
expect Emacs to automatically load all required files. So, in this
concrete case, I would expect Emacs to automatically load cl, cl-lib, or
cl-macs, or whatever is necessary to use cl-letf. If it does not do
this, my impression is that the macro shall not be called autoloaded, on
the grounds that the required definitions are not automatically loaded.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#33901
; Package
emacs
.
(Mon, 31 Dec 2018 00:46:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 33901 <at> debbugs.gnu.org (full text, mbox):
This is a specific instance of the general problem described in
https://debbugs.gnu.org/26782
As such, I would suggest closing this report, since I don't think it
adds anything new.
bug closed, send any further explanations to
33901 <at> debbugs.gnu.org and Markus Triska <triska <at> metalevel.at>
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 04 Jan 2019 06:01:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 01 Feb 2019 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 287 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.