Re: Strange eval-after-load

[Stuart D. Herring]

>    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?

My apologies if I misunderstand, but it looks like you don't realize that
`after-load-alist' is precisely the implementation of `eval-after-load'. 
(The fact that Fprogn() is called allows `eval-after-load' to put multiple
forms on the alist, thus resolving the "cooperation" issue (to an
extent).)  So of course this is just as verboten as `eval-after-load' is,
as it is `eval-after-load'.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.