unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Strange eval-after-load
Date: Wed, 5 Jul 2006 09:57:31 +0100	[thread overview]
Message-ID: <20060705085731.GB1418@muc.de> (raw)
In-Reply-To: <ulkr8rb3q.fsf@gnu.org>

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?

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

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

Why is this bad?  Edebug provides the function `def-edebug-spec'
specifically to allow Edebug's behaviour to be modified thusly.  Why is
it OK to do this in a direct call, but not OK within an eval-after-load?
Wherein lies the essential difference?

> Btw, the original text I wrote for this tip was a bit different, it
> explicitly said that eval-after-load increases a coupling between the
> two packages, which is a maintenance burden:
> 
>     Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
>     Loading}) in libraries and packages.  This feature is meant for
>     personal customizations; using it in a Lisp package increases the
>     coupling between it and the package mentioned in
>     @code{eval-after-load}, and thus makes it harder to maintain the two
>     packages independently.

How does eval-after-load change the coupling?  It seems to me that all
the nasty coupling things that can happen, like accessing global
variables, implicitly sharing data structurings, etc., are completely
orthogonal to eval-after-load.

eval-after-load _decreases_ the "coupling" in an important sense - it
allows CC Mode to run without forcing Edebug to be loaded.

It is true that e-a-l makes the code more difficult to read, but then,
so do things like ,@ inside macros.

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

-- 
Alan.

  reply	other threads:[~2006-07-05  8:57 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 [this message]
2006-07-05  9:09                       ` David Kastrup
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=20060705085731.GB1418@muc.de \
    --to=acm@muc.de \
    --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).