Re: eval-after-provision

"Stephen J. Turnbull" <[email protected]> writes:

> >>>>> "Reiner" == Reiner Steib <[email protected]> writes:
> 
>     Reiner> AFAICS, in GNU Emacs (CVS), `eval-after-load' already
>     Reiner> allows what you suggest.  It would be nice if XEmacs would
>     Reiner> use a compatible interface.
> 
> We already have the compatible interface, but it's broken by design.
> That's the point.  Unless Emacs CVS changes the semantics, which would
> be even more broken.

If I'm understanding their code correctly, what they do is do the
normal stuff in eval-after-load, and then also in provide do 
(taken from the code for provide in fns.c):

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

This is closer to my simple version of advising provide, using
after-load-alist instead of a separate variable and relying on the
fact that load uses strings whereas provide uses symbols so that they
can coexist within the same alist.

I can see why Jeff Mincy's more controlled approach would be nicer in
some situations (e.g., mutual recursion), but it *would* represent a
compatibility issue with gnu emacs. If his approach were adapted, it'd
be easy enough to change eval-after-load to call after-provided
instead, but there'd be a deeper incompatibility of when the
evaluation actually occurs. 

Jeff, do you think your approach would be suitable for inclusion in
xemacs? I could go ahead and make up a new patch with your code, if
that's ok... ? (Your code looks good to me, although that's really not
saying much :-). I suppose a few places I'm curious if an
unwind-protect might be more suitable than condition-case and
re-signalling the error, but that's just a quibble, I think...

-- 
I'm awfully glad I'm a Beta, because I don't work so hard.