Re: Strange eval-after-load

[Alan Mackenzie]

On Tue, Jul 04, 2006 at 09:15:53AM +0200, David Kastrup wrote:
> Alan Mackenzie <address@hidden> 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)