GNU bug report logs -
#15389
24.2.91; order of eval-after-load actions
Previous Next
Reported by: joaotavora <at> gmail.com (João Távora)
Date: Sun, 15 Sep 2013 22:42:02 UTC
Severity: wishlist
Found in version 24.2.91
Fixed in version 24.4
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 15389 in the body.
You can then email your comments to 15389 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#15389
; Package
emacs
.
(Sun, 15 Sep 2013 22:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
joaotavora <at> gmail.com (João Távora)
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 15 Sep 2013 22:42:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi maintainers,
Consider a file foo-test.el consisting of this content
(eval-after-load 'foo
`(progn
(message "foo1")))
(eval-after-load 'foo
`(progn
(message "foo2")))
(provide 'foo)
If I interactively eval these forms in order using `eval-last-sexp', for
example I get
foo1
foo2
in the *Messages* buffer. But if i load the file like so
emacs -Q --batch -l foo-test.el
I get
foo2
foo1
Is this the expected behaviour? Shouldn't the order in which the hooks
are run match the order of definition.
In GNU Emacs 24.2.91.1 (x86_64-apple-darwin11.4.2, Carbon Version 1.6.0 AppKit 1138.51)
of 2012-12-25 on king
Windowing system distributor `Apple Inc.', version 10.7.5
Configured using:
`configure '--prefix=/usr/local/Cellar/emacs-mac/HEAD'
'--enable-locallisppath=/usr/local/share/emacs/site-lisp'
'--infodir=/usr/local/Cellar/emacs-mac/HEAD/share/info/emacs'
'--with-mac' '--enable-mac-app' 'CC=cc''
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15389
; Package
emacs
.
(Mon, 16 Sep 2013 06:59:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 15389 <at> debbugs.gnu.org (full text, mbox):
João Távora wrote:
> Is this the expected behaviour? Shouldn't the order in which the hooks
> are run match the order of definition.
I don't think eval-after-load promises anything about the order of
evaluation. At the moment, it works like add-hook, ie adds to the front
of the list. Do you have an example where it actually matters?
> In GNU Emacs 24.2.91.1 (x86_64-apple-darwin11.4.2, Carbon Version 1.6.0 AppKit 1138.51)
BTW, there's zero reason to use that anymore since 24.3 was released.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15389
; Package
emacs
.
(Mon, 16 Sep 2013 11:18:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 15389 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> João Távora wrote:
>
>> Is this the expected behaviour? Shouldn't the order in which the hooks
>> are run match the order of definition.
>
> I don't think eval-after-load promises anything about the order of
> evaluation. At the moment, it works like add-hook, ie adds to the front
> of the list.
Well, add-hook has an `append' option right? That would be nice.
> Do you have an example where it actually matters?
Yes. I use small configuration files that are loaded in a particular
order to configure emacs in different flavors, an idea that I took from
debian, i believe, some years ago.
For example, take gnus. If I activate the "common" and "work" flavors in
that order, (which I do when I'm at work) the statements in the "work"
flavor will sometimes overwrite settings that I set in the "common"
flavor, like a different smtp servers.
It all worked fine until I remembered to introduce eval-after-load to
make startup faster.
I could possibly, for instance, never `setq' a variable directly in the
progn body passed to eval-after-load.
Using a million mode-specific hooks I could ensure that "work" always
takes precedence. But this would defeat the purpose of my simple
directories-flavors and 33some-foo-config.el scheme, which has served me
wonderfully for years now and relies on this simple feature of lisp.
But it would just be neater if the order of appearance matched the order
of evaluation.
I don't have to use eval-after-load. Isn't there another similar
mechanism? Where can I start looking?
>> In GNU Emacs 24.2.91.1 (x86_64-apple-darwin11.4.2, Carbon Version 1.6.0 AppKit 1138.51)
>
> BTW, there's zero reason to use that anymore since 24.3 was released.
There's a reason: this one's working fine. It takes me time and patience
to compile another emacs with my fullscreen patches.
Thanks,
João
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15389
; Package
emacs
.
(Mon, 16 Sep 2013 16:31:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 15389 <at> debbugs.gnu.org (full text, mbox):
> If I interactively eval these forms in order using `eval-last-sexp', for
> example I get
> foo1
> foo2
> in the *Messages* buffer. But if i load the file like so
> emacs -Q --batch -l foo-test.el
> I get
> foo2
> foo1
> Is this the expected behaviour?
No, indeed, thank you for the clear test case.
Should now be fixed in the emacs-24 branch with the trivial patch below.
Stefan
--- lisp/subr.el 2013-07-03 03:13:07 +0000
+++ lisp/subr.el 2013-09-16 16:28:00 +0000
@@ -1872,7 +1872,7 @@
nil
(remove-hook 'after-load-functions ',fun)
,',form)))
- (add-hook 'after-load-functions fun))
+ (add-hook 'after-load-functions fun 'append))
;; Not being provided from a file, run form right now.
,form)))
;; Add FORM to the element unless it's already there.
bug marked as fixed in version 24.4, send any further explanations to
15389 <at> debbugs.gnu.org and joaotavora <at> gmail.com (João Távora)
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Mon, 16 Sep 2013 16:38:03 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
.
(Tue, 15 Oct 2013 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 249 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.