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 11:04:32 +0100 Message-ID: <20060704100432.GB1316@muc.de> References: <20060702133304.GA4008@muc.de> <20060703105727.GA2626@muc.de> <85ac7rouo6.fsf@lola.goethe.zz> <20060703135010.GB2626@muc.de> <20060704080222.GA1316@muc.de> <853bdhkfh2.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1152003972 17380 80.91.229.2 (4 Jul 2006 09:06:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Jul 2006 09:06:12 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 04 11:06:10 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 1Fxgqx-0008Iv-RU for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 11:05:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fxgqx-0004ZW-9v for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 05:05:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FxgqY-0004U1-4g for emacs-devel@gnu.org; Tue, 04 Jul 2006 05:05:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FxgqV-0004Sf-8Z for emacs-devel@gnu.org; Tue, 04 Jul 2006 05:05:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxgqU-0004SV-Sy for emacs-devel@gnu.org; Tue, 04 Jul 2006 05:05:26 -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 1Fxh48-0008TV-23 for emacs-devel@gnu.org; Tue, 04 Jul 2006 05:19:32 -0400 Original-Received: (qmail 13662 invoked from network); 4 Jul 2006 09:05:23 -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 09:05:23 -0000 Original-Received: from acm by localhost.localdomain with local (Exim 4.50) id 1Fxhlg-0000pq-2H; Tue, 04 Jul 2006 11:04:32 +0100 Original-To: David Kastrup Content-Disposition: inline In-Reply-To: <853bdhkfh2.fsf@lola.goethe.zz> 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:56473 Archived-At: On Tue, Jul 04, 2006 at 09:15:53AM +0200, David Kastrup wrote: > Alan Mackenzie writes: > > Morning, Richard! > > On Mon, Jul 03, 2006 at 07:21:15PM -0400, Richard Stallman wrote: > >> I think people will either just quietly commit > >> eval-after-loads, or they'll write clumsy abstruse workarounds. > >> If people try to sneak them in, I will do something about them. > > :-) > >> The "clumsy workarounds" might actually be superior, for maintenance > >> purposes. That's the reason for this policy: so people will take the > >> trouble to use those "clumsy" workarounds, instead of taking the > >> inferior lazy way out. > > Richard, please tell me what's wrong with using eval-after-load. > > I've been trying to get an answer to this question in post after > > post after post, and all replies have been evasive. Everybody else > > has been writing as though it were perfectly obvious and > > uncontrovertible that eval-after-load is bad. It's anything but > > obvious to me. > Like defadvice, it is hooking into parts of a package that are lacking > a proper interface. Not true in general. e-a-l doesn't "hook into" packages. It calls lisp forms. The lisp forms it calls need not be (and should not be) undefined interfaces. In my favourite example, `def-edebug-spec' is a perfectly well defined interface. Or have I misunderstood what you mean? > It is not guaranteed to continue to work, Whhaaat? Is _any_ part of Emacs "guaranteed" to work? If you mean that eval-after-load is buggy, I think that the fixes I applied to it in May fix those bugs. If not, it should be fixed, just like any other part of Emacs. > its effects are not certain when you are loading a package more than > once, I fixed the doc-string and Elisp manual to state that the e-a-l forms are executed _each_ time the package is loaded. Any uncertainties are due to the forms in e-a-l, not e-a-l itself. > it makes debugging a pain. That surely depends on how it is used. You would not, I think, assert that (eval-after-load "edebug" '(def-edebug-spec ...)) causes any debugging difficulties at all. On the contrary, it assists debugging. Please substantiate your assertion. Give me an example of a non-silly use of e-a-l that hinders debugging. Please show me how the alternative would be better. There are (or until recently were) over 70 e-a-l's in the Emacs source. This isn't a rhetorical thrust - I genuinely want to find out. > If there is a missing interface, the proper solution is to create it, ??? eval-after-load doesn't deal with "missing interfaces". It deals with calling functions (usually well-defined) which haven't yet been loaded. The forms in e-a-l are usually well defined interfaces, such as `def-edebug-spec' or `require'. Or do you mean something else? > not fudge something onto a package that might stop working at some time. eval-after-load is now well defined, and works as predictably as anything else. I wouldn't call the use of `def-edebug-spec' "fudging something onto a package". As somebody who switches Font Lock off, what would you put in cc-mode.el for GNU Emacs 21 in place of the following form: (eval-after-load "font-lock" '(require 'cc-fonts)) ? Note that cc-fonts won't load without Font Lock first being loaded, and the user who hates Font Locking doesn't want his store clogged up with it. > David Kastrup, Kriemhildstr. 15, 44793 Bochum -- Alan Mackenzie (Munich, Germany)