From: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Strange eval-after-load
Date: Tue, 4 Jul 2006 11:04:32 +0100 [thread overview]
Message-ID: <20060704100432.GB1316@muc.de> (raw)
In-Reply-To: <853bdhkfh2.fsf@lola.goethe.zz>
On Tue, Jul 04, 2006 at 09:15:53AM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > Morning, Richard!
> > On Mon, Jul 03, 2006 at 07:21:15PM -0400, Richard Stallman wrote:
> >> I think people will either just quietly commit
> >> eval-after-loads, or they'll write clumsy abstruse workarounds.
> >> If people try to sneak them in, I will do something about them.
> > :-)
> >> The "clumsy workarounds" might actually be superior, for maintenance
> >> purposes. That's the reason for this policy: so people will take the
> >> trouble to use those "clumsy" workarounds, instead of taking the
> >> inferior lazy way out.
> > Richard, please tell me what's wrong with using eval-after-load.
> > I've been trying to get an answer to this question in post after
> > post after post, and all replies have been evasive. Everybody else
> > has been writing as though it were perfectly obvious and
> > uncontrovertible that eval-after-load is bad. It's anything but
> > obvious to me.
> Like defadvice, it is hooking into parts of a package that are lacking
> a proper interface.
Not true in general. e-a-l doesn't "hook into" packages. It calls lisp
forms. The lisp forms it calls need not be (and should not be) undefined
interfaces. In my favourite example, `def-edebug-spec' is a perfectly
well defined interface.
Or have I misunderstood what you mean?
> It is not guaranteed to continue to work,
Whhaaat? Is _any_ part of Emacs "guaranteed" to work? If you mean that
eval-after-load is buggy, I think that the fixes I applied to it in May
fix those bugs. If not, it should be fixed, just like any other part of
Emacs.
> its effects are not certain when you are loading a package more than
> once,
I fixed the doc-string and Elisp manual to state that the e-a-l forms are
executed _each_ time the package is loaded. Any uncertainties are due to
the forms in e-a-l, not e-a-l itself.
> it makes debugging a pain.
That surely depends on how it is used. You would not, I think, assert
that (eval-after-load "edebug" '(def-edebug-spec ...)) causes any
debugging difficulties at all. On the contrary, it assists debugging.
Please substantiate your assertion. Give me an example of a non-silly
use of e-a-l that hinders debugging. Please show me how the alternative
would be better. There are (or until recently were) over 70 e-a-l's in
the Emacs source. This isn't a rhetorical thrust - I genuinely want to
find out.
> If there is a missing interface, the proper solution is to create it,
??? eval-after-load doesn't deal with "missing interfaces". It deals
with calling functions (usually well-defined) which haven't yet been
loaded.
The forms in e-a-l are usually well defined interfaces, such as
`def-edebug-spec' or `require'. Or do you mean something else?
> not fudge something onto a package that might stop working at some time.
eval-after-load is now well defined, and works as predictably as anything
else. I wouldn't call the use of `def-edebug-spec' "fudging something
onto a package".
As somebody who switches Font Lock off, what would you put in cc-mode.el
for GNU Emacs 21 in place of the following form:
(eval-after-load "font-lock" '(require 'cc-fonts))
? Note that cc-fonts won't load without Font Lock first being loaded,
and the user who hates Font Locking doesn't want his store clogged up
with it.
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
--
Alan Mackenzie (Munich, Germany)
next prev parent reply other threads:[~2006-07-04 10:04 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
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 [this message]
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=20060704100432.GB1316@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.