GNU bug report logs -
#16810
24.3.50; `with-eval-after-load'
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Wed, 19 Feb 2014 17:02:01 UTC
Severity: minor
Merged with 26888
Found in versions 24.3.50, 25.2
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 16810 in the body.
You can then email your comments to 16810 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#16810
; Package
emacs
.
(Wed, 19 Feb 2014 17:02: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
.
(Wed, 19 Feb 2014 17:02:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
1. The NEWS entry is not helpful enough:
"This is like the old `eval-after-load', but better behaved."
What does that even mean? How so? How is it like it? How is it
different? What is "better" about the (unspecified) behavior
difference? Why was the macro introduced?
The main difference I can see, based on the available doc, is that
the macro evaluates the BODY "*each time* LIBRARY is loaded". Is
that considered "better behaved"? Why?
That important difference (assuming the manual is correct about that)
is not even mentioned in the doc string. And it is not stressed in
the Elisp manual - you have to read carefully to get it.
Other, obvious differences, which I can hardly imagine to constitute
"better" behavior and so call for introducing this macro, let alone
replacing `eval-after-load' with it, are (a) that it is a macro, so
you do not need to quote its arg (and so cannot pass it something to
be evaluated) and (b) that it uses an implicit `progn'. What else is
different?
2. The doc string is not helpful enough.
Compare the doc string of `eval-after-load' with this doc string.
Someone actually tried (and succeeded) to describe what
`eval-after-load' does.
3. Elisp manual:
`eval-after-load' is referenced multiple times, but it is not
described/specified. Its description has been removed from the
manual. It needs to be reinstated.
The Elisp manual says that`eval-after-load' is primarily for users
(e.g., in their init files), not for Lisp libraries. But the Emacs
manual also does not describe it. This does not help users.
The doc for both `eval-after-load' and `with-eval-after-load' is now
incomplete and confusing.
4. Posts here and there (e.g.,
http://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00270.html)
suggest that `eval-after-load' is being replaced by
`with-eval-after-load'. All the more reason to document the proposed
new at least as well as the old was documented.
5. I can find no proposal or discussion of `with-eval-after-load' in
either emacs-devel or the bug list. It seems to have just appeared,
followed by a few statements here and there suggesting that it is
replacing `eval-after-load'. What happened to proposal >
discussion > implementation & doc? What problem is this solution
trying to solve?
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2014-02-11 on ODIEONE
Bzr revision: 116410 lekktu <at> gmail.com-20140211204823-l9l2s6tktfitq266
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
CPPFLAGS=-Ic:/Devel/emacs/include'
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16810
; Package
emacs
.
(Wed, 19 Feb 2014 18:46:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 16810 <at> debbugs.gnu.org (full text, mbox):
Another important difference is of course that for the macro the BODY will
be byte-compiled. That too might be worth pointing out.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16810
; Package
emacs
.
(Wed, 19 Feb 2014 19:09:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 16810 <at> debbugs.gnu.org (full text, mbox):
Some brief comments.
> The main difference I can see, based on the available doc, is that
> the macro evaluates the BODY "*each time* LIBRARY is loaded". Is
> that considered "better behaved"? Why?
Docstring for eval-after-load says:
If a matching file is loaded again, form will be evaluated again.
so how is that different?
> Other, obvious differences, which I can hardly imagine to constitute
> "better" behavior and so call for introducing this macro, let alone
> replacing `eval-after-load' with it, are (a) that it is a macro, so
> you do not need to quote its arg
To me, that's a big difference which makes the macro much "better". YMMV.
> 2. The doc string is not helpful enough.
Agreed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16810
; Package
emacs
.
(Wed, 19 Feb 2014 19:32:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 16810 <at> debbugs.gnu.org (full text, mbox):
> Docstring for eval-after-load says:
>
> If a matching file is loaded again, form will be evaluated again.
>
> so how is that different?
Good catch; it's not different - my bad.
[Although it perhaps used to be different (?). The doc string said
at one point:
"It does nothing if FORM is already on the list for FILE."
("The list" here refers to `after-load-alist'.)]
Merged 16810 26888.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Thu, 11 May 2017 16:31:01 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
26888 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 05 Feb 2021 12:53: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
.
(Sat, 06 Mar 2021 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 52 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.