all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Strange eval-after-load
Date: Mon, 3 Jul 2006 11:57:28 +0100	[thread overview]
Message-ID: <20060703105727.GA2626@muc.de> (raw)
In-Reply-To: <E1FxASt-0001Lh-Mz@fencepost.gnu.org>

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	other threads:[~2006-07-03 10:57 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-26  2:22 Strange eval-after-load Richard Stallman
2006-05-26  7:59 ` Eli Zaretskii
2006-05-26 14:20   ` Luc Teirlinck
2006-05-26 19:32     ` Eli Zaretskii
2006-05-27  3:36   ` Richard Stallman
2006-07-02 13:33 ` Hi, I'm back! + " Alan Mackenzie
2006-07-02 17:28   ` Thien-Thi Nguyen
2006-07-02 19:18     ` Alan Mackenzie
2006-07-03 15:05       ` Richard Stallman
2006-07-03 17:16         ` Alan Mackenzie
2006-07-03 16:28           ` Michael Albinus
2006-07-03 17:06           ` John Paul Wallington
2006-07-03 21:54             ` Alan Mackenzie
2006-07-03 21:48               ` Johan Bockgård
2006-07-04 12:54           ` Richard Stallman
2006-07-04 15:02             ` Alan Mackenzie
2006-07-04 20:52               ` Richard Stallman
2006-07-04 21:41                 ` Bob Rogers
2006-07-05 16:38                   ` Stuart D. Herring
2006-07-05 17:01                   ` Richard Stallman
2006-07-02 22:30   ` Hi, I'm back! + " Richard Stallman
2006-07-03 10:57     ` Alan Mackenzie [this message]
2006-07-03 10:21       ` David Kastrup
2006-07-03 13:50         ` Alan Mackenzie
2006-07-03 23:21           ` Richard Stallman
2006-07-04  8:02             ` Alan Mackenzie
2006-07-04  7:15               ` David Kastrup
2006-07-04 10:04                 ` Alan Mackenzie
2006-07-04  9:23                   ` David Kastrup
2006-07-04 10:00                     ` Nick Roberts
2006-07-04 13:08                       ` Johan Bockgård
2006-07-04 14:17               ` Thien-Thi Nguyen
2006-07-04 17:30               ` Richard Stallman
2006-07-04 21:08                 ` Alan Mackenzie
2006-07-04 21:48                   ` Nick Roberts
2006-07-05  3:20                   ` Eli Zaretskii
2006-07-05  8:57                     ` Alan Mackenzie
2006-07-05  9:09                       ` David Kastrup
2006-07-05 22:28                         ` Alan Mackenzie
2006-07-06  6:49                           ` David Kastrup
2006-07-07  4:14                           ` Richard Stallman
2006-07-07 11:46                             ` Alan Mackenzie
2006-07-05 17:02                     ` Richard Stallman
2006-07-05 14:51                   ` Richard Stallman
2006-07-05 18:01                     ` Alan Mackenzie
2006-07-03 23:21       ` Richard Stallman
2006-07-03 23:21       ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060703105727.GA2626@muc.de \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.