From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Strange eval-after-load Date: Tue, 4 Jul 2006 22:08:05 +0100 Message-ID: <20060704210805.GF1316@muc.de> References: <20060702133304.GA4008@muc.de> <20060703105727.GA2626@muc.de> <85ac7rouo6.fsf@lola.goethe.zz> <20060703135010.GB2626@muc.de> <20060704080222.GA1316@muc.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1152043749 26454 80.91.229.2 (4 Jul 2006 20:09:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Jul 2006 20:09:09 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 04 22:09:06 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FxrCM-0003nJ-11 for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 22:08:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxrCL-00014b-J1 for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 16:08:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FxrCC-00014W-6w for emacs-devel@gnu.org; Tue, 04 Jul 2006 16:08:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FxrC9-00014K-SA for emacs-devel@gnu.org; Tue, 04 Jul 2006 16:08:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxrC9-00014H-LM for emacs-devel@gnu.org; Tue, 04 Jul 2006 16:08:29 -0400 Original-Received: from [193.149.48.1] (helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FxrPt-0007qR-EV for emacs-devel@gnu.org; Tue, 04 Jul 2006 16:22:41 -0400 Original-Received: (qmail 71431 invoked from network); 4 Jul 2006 20:08:26 -0000 Original-Received: from acm.muc.de (HELO localhost.localdomain) (Debian-exim@193.149.49.134) by mail.muc.de with SMTP; 4 Jul 2006 20:08:26 -0000 Original-Received: from acm by localhost.localdomain with local (Exim 4.50) id 1Fxs7p-0003DK-G9; Tue, 04 Jul 2006 22:08:05 +0100 Original-To: Richard Stallman Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:56521 Archived-At: On Tue, Jul 04, 2006 at 01:30:17PM -0400, Richard Stallman wrote: > Richard, please tell me what's wrong with using eval-after-load. > Here's the explanation from tips.texi. [ .... ] > @item > It is likewise a bad idea for one Lisp package to advise a function > in another Lisp package. > @item > 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 program is unclean because > it modifies the behavior of another Lisp file in an invisible way. > This is an obstacle for debugging, much like advising a function in > the other package. (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. [Just for clarity, this point is independent of the precise semantics of `def-edebug-spec'. I think it is also the case that `def-edebug-spec' doesn't modify edebug's state at all.] -- Alan.