Re: Strange eval-after-load

[David Kastrup]

Alan Mackenzie <address@hidden> writes:

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

So does defadvice.  You are trying to play semantic games here.

> 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.

It is not guaranteed to continue to work because it uses a package
mechanisms in ways that are not designed for it.

>> 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.

Which won't work for most instances of eval-region and similar, and
the user can't actually see why or fix it since no user-visible
variable contains the info what is supposed to be happening.

>> 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.

You are playing semantic games again.

> Please substantiate your assertion.  Give me an example of a
> non-silly use of e-a-l that hinders debugging.

Any you like, because it causes unpredictable side effects if (and
only if) the `provide' line gets executed.  `provide''s DOC-string
does not even mention `eval-after-load'.

> 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.

Using an interface for delayed effects that is _documented_ in the
source file of a module and where you can check a dedicated variable
for what will be happening instead of things magically happening at
`provide' time because some other library did an eval-after-load
(which will, BTW, likely cause havoc if you unload-feature that
library, as eval-after-load can't be undone) is just not the same
thing.

>> 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.

You are again playing semantic games.  `eval-after-load' is used in
lack of any other interface for achieving the same results.

> 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))

(if (featurep 'font-lock)
    (require 'cc-fonts)
  (add-hook 'font-lock-mode-hook '(lambda nil (require 'cc-fonts))))

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum