unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Strange eval-after-load
Date: Wed, 05 Jul 2006 11:09:24 +0200	[thread overview]
Message-ID: <85ejx0e7uj.fsf@lola.goethe.zz> (raw)
In-Reply-To: <20060705085731.GB1418@muc.de> (Alan Mackenzie's message of "Wed, 5 Jul 2006 09:57:31 +0100")

Alan Mackenzie <acm@muc.de> 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 <acm@muc.de>
>> > Cc: emacs-devel@gnu.org
>
>> > (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	other threads:[~2006-07-05  9:09 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
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 [this message]
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85ejx0e7uj.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=eliz@gnu.org \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).