unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Strange eval-after-load
Date: Wed, 5 Jul 2006 23:28:51 +0100	[thread overview]
Message-ID: <20060705222851.GC1992@muc.de> (raw)
In-Reply-To: <85ejx0e7uj.fsf@lola.goethe.zz>

On Wed, Jul 05, 2006 at 11:09:24AM +0200, David Kastrup wrote:
> 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?

> The change is not visible where it happens, namely at the (provide 'edebug).

That is WHEN the change happens.  Loading edebug is the trigger.  I'm
not sure what you mean by "where", here.  Do you mean the module whose
data is changed?  Or do you mean the module whose functions make the
change?  If you could say what you wanted to see and why, that might
help me.

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

Don't all hooks work this way?  What do you mean by "visible"?  I'm
sorry, but the rest of the paragraph is too vague to make any sense to
me.  A call happening without user-accessible variables or a hook is
like a cuckoo clock chiming without Pythagoras's theorem.  There are
several behaviours which you could mean by "the" behaviour.  When would
a user want to access these variables, and why?  What would be the
purpose of using a hook to modify whichever behaviour?

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

It's no more or less difficult that tracking down every place a hook is
used.  eval-after-load is conceptually the same as add-hook.  Why is
using e-a-l worse than using LaTeX-mode-hook,  for example?

> >> 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.
 
Resorts to hand waving abstractions have been made, but no descent to the
concrete.  I think that you and Richard and Eli must have experienced
problems with eval-after-load - I've not.  The only problems I've had
with it were those cause by bugs in its code and documentation, not its
use, and I've tried to fix these bugs.

Since I haven't experienced these problems, the level of abstraction you
have been talking at is meaningless to me.  It's obvious that
eval-after-load can be used very stupidly, but that's not the point.

I cannot conceive of any (real) problems which might be caused by

   (eval-after-load "edebug" '(def-edebug-spec c-point t))

If you're still willing to carry on trying to help me get the point,
perhaps you could cite a specific problem caused by a specific
"nice" use of eval-after-load.  I'd be grateful.

> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Munich, Germany)

  reply	other threads:[~2006-07-05 22:28 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
2006-07-05 22:28                         ` Alan Mackenzie [this message]
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=20060705222851.GC1992@muc.de \
    --to=acm@muc.de \
    --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).