[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
- Re: Strange eval-after-load, (continued)
- Re: Strange eval-after-load, Thien-Thi Nguyen, 2006/07/04
- Re: Strange eval-after-load, Richard Stallman, 2006/07/04
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/04
- Re: Strange eval-after-load, Nick Roberts, 2006/07/04
- Re: Strange eval-after-load, Eli Zaretskii, 2006/07/04
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/05
- Re: Strange eval-after-load,
David Kastrup <=
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/06
- Re: Strange eval-after-load, David Kastrup, 2006/07/06
- Re: Strange eval-after-load, Richard Stallman, 2006/07/07
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/07
- Re: Strange eval-after-load, Richard Stallman, 2006/07/05
- Re: Strange eval-after-load, Richard Stallman, 2006/07/05
- Re: Strange eval-after-load, Alan Mackenzie, 2006/07/05
- Re: Strange eval-after-load, Richard Stallman, 2006/07/03
- Re: Strange eval-after-load, Richard Stallman, 2006/07/03