emacs-devel
[Top][All Lists]
Advanced

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

Re: Strange eval-after-load


From: Alan Mackenzie
Subject: Re: Strange eval-after-load
Date: Mon, 3 Jul 2006 11:57:28 +0100
User-agent: Mutt/1.5.9i

Morning, Richard!

On Sun, Jul 02, 2006 at 06:30:55PM -0400, Richard Stallman wrote:
>     > Starting immediately, please do NOT install calls to eval-after-load
>     > in Emacs without asking for my specific approval.
> 
>     I would beg you not to be so dogmatic.

> This rule is the only way to get control over the situation.

I don't really understand what the situation is over which control has
to be got.  It is possible to to use eval-after-load badly, just as it
is possible to use goto badly.  That's a far cry from demonstrating that
all e-a-l's/goto's are bad.

>       For example, in
>     cc-defs.el, we have:
> 
>       ;; Make edebug understand the macros.
>       (eval-after-load "edebug"
>         '(progn
>              (def-edebug-spec cc-eval-when-compile t)
>              (def-edebug-spec c-point t)

> Isn't there now a defun feature for doing this?

There is, and thanks to Thi for telling me about it.  However, this new
`declare' feature in defmacro seems to be a bit ad-hoc.  Since it
doesn't exist in older Emacsen, it's not suitable for packages like CC
Mode, which will continue to need edebugging on these other (X)Emacsen.

I really don't want to contemplate anything like a macro `meta-macro'
where

    (meta-macro c-lang-defvar ...... t)

would expand to a `defmacro' containing a `declare' in Emacs 22, and to
a `defmacro' followed by `(eval-after-load "edebug" ...)' in other
Emacsen.  I can't see any other way around this problem.  I absolutely
do not want to take these `(eval-after-load "edebug" ...)'s out of CC
Mode, because it would create so much hassle for no gain that I can see
(and I'll admit I'm struggling to keep up with all the work on CC Mode
as it is).

However, the main point of that example from cc-defs.el was not to plead
it as a special case, but to demonstrate the existence of a good use of
eval-after-load.  Nobody, not even yourself, has said that that code
snippet is intrinsically bad.  There will surely be other uses of
eval-after-load which are just as useful and necessary.

Rather than banning eval-after-load, why not formulate when it is
acceptable to use it, and put this advice into the Elisp manual?

-- 
Alan.





reply via email to

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