[Top][All Lists]

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

Re: Strange eval-after-load

From: David Kastrup
Subject: Re: Strange eval-after-load
Date: Wed, 05 Jul 2006 11:09:24 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Alan Mackenzie <address@hidden> writes:

> On Wed, Jul 05, 2006 at 06:20:41AM +0300, Eli Zaretskii wrote:
>> > Date: Tue, 4 Jul 2006 22:08:05 +0100
>> > From: Alan Mackenzie <address@hidden>
>> > Cc: address@hidden
>> > (eval-after-load "edebug" '(def-edebug-spec c-point t))
>> > To construe this form as "modifying the behaviour of another Lisp file
>> > (?edebug, presumably) in an invisible way" seems like a total perversion
>> > of reality to me.  I would call this e-a-l "Telling another Lisp file
>> > how to handle the current one" - in essence, the module which is
>> > modified by this e-a-l is cc-defs, not edebug.
>> Doesn't "Telling another Lisp file how to handle the current one"
>> modify the behavior of that other package in a way that isn't visible
>> if you look at the code of that other package?
> Whether it does or not is surely independent of whether
> `def-edebug-spec' is called directly, or through eval-after-load.
> Again, this change is just as visible, whichever way the function is
> called.  Surely?

Again, you are playing semantic games.  The change is not visible
where it happens, namely at the (provide 'edebug).

> There is nothing objectionable about using the documented functional
> interface `def-edebug-spec'.

Straw man.  Nobody objected to its use.  What is objectional is that
its call happens at the (provide 'edebug) line without any visible
indication in edebug.el, and without any user-accessible variables or
hook that would allow for inspection and modification of the behavior.
A user won't have cause to be surprised if he added eval-after-load
himself.  But expecting and tracking every such use that might be
hidden in Emacs' code base is a bit much.

>> In your example above, Edebug's behavior is modified, but one cannot
>> know that by reading Edebug's code alone.
> Why is this bad?

The reasons have been cited to you several times and it is in the
manual which also has been cited to you.

I think you are blinded by your wishes.

> I still don't understand.  I'm trying to.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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