[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15389: 24.2.91; order of eval-after-load actions

From: João Távora
Subject: bug#15389: 24.2.91; order of eval-after-load actions
Date: Mon, 16 Sep 2013 12:17:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (darwin)

Glenn Morris <address@hidden> 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 (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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]