[Top][All Lists]

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

Re: Strange eval-after-load

From: Bob Rogers
Subject: Re: Strange eval-after-load
Date: Tue, 4 Jul 2006 17:41:29 -0400

   From: Richard Stallman <address@hidden>
   Date: Tue, 04 Jul 2006 16:52:53 -0400

       I'm sure this isn't the only such example.  As a more general solution
       (with the idea coming from David Kastrup), how about each "utility"
       library having an initialisation hook, along the lines of

   This is a good solution, but since it is a certain amount of work to
   set this up in each package, we do it only for the packages that need

Two observations:

   1.  It seems to me this can be done without any setup work on the
part of the package.  Suppose the provide routine were changed to run a
specified hook, e.g. "foo-provide-hook" if "(provide 'foo)" were
executed, and the symbol "foo" was not already on the "features" list?
That would seem to be more or less equivalent to eval-after-load, but
less magical, and without file synonym issues.  (Maybe that's not the
best idea for the hook name, but at least there are no "-provide-hook"
hits in the codebase at present.)

   2.  I notice that Fprovide already does something related, but using
after-load-alist instead of a per-package hook:

        /* Run any load-hooks for this file.  */
        tem = Fassq (feature, Vafter_load_alist);
        if (CONSP (tem))
          Fprogn (XCDR (tem));

(This is documented for after-load-alist, BTW, but not for provide.)
But this seems to have semantic problems of its own.  What if two
packages independently decide to use this mechanism for the same third
package?  It would be somewhat tricky for them to cooperate.  Does this
other use of after-load-alist also fall under your injunction not to use
eval-after-load without first asking?

                                        -- Bob Rogers

reply via email to

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