From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Strange eval-after-load Date: 04 Jul 2006 10:17:31 -0400 Message-ID: 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 1152022709 14893 80.91.229.2 (4 Jul 2006 14:18:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Jul 2006 14:18:29 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 04 16:18:25 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 1FxljG-0001h1-Hs for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 16:18:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FxljF-0007zX-Vx for ged-emacs-devel@m.gmane.org; Tue, 04 Jul 2006 10:18:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fxlj2-0007y2-SF for emacs-devel@gnu.org; Tue, 04 Jul 2006 10:18:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fxlj1-0007xW-97 for emacs-devel@gnu.org; Tue, 04 Jul 2006 10:18:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fxlj0-0007xJ-V8 for emacs-devel@gnu.org; Tue, 04 Jul 2006 10:18:03 -0400 Original-Received: from [67.59.132.6] (helo=mail.agora-net.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Fxlwh-0002kp-Qe for emacs-devel@gnu.org; Tue, 04 Jul 2006 10:32:11 -0400 Original-Received: from ttn by mail.agora-net.com with local (Exim 4.50) id 1FxliV-0003KK-OH; Tue, 04 Jul 2006 10:17:31 -0400 Original-To: Alan Mackenzie In-Reply-To: <20060704080222.GA1316@muc.de> Original-Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 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:56495 Archived-At: Alan Mackenzie writes: > 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. the fewer axioms, the more obvious the proofs, no? using `eval-after-load' introduces complexity at the maintenance level in order to hide that complexity at the user level. that is, it is a feature intended for users who may not care much about the consequences of its use. maintainers, on the other hand, always care about such consequences because time spent understanding complex interdependent behavior is time not spent hacking (or doing other maintenance). people have a different feel for "complex interdependent behavior" and a different valuation for it when they recognize it, so a one- or two-link chain (of loading, of coding, of debugging, of required reasoning, etc) may not seem excessive to one but may seem extremely tedious to another. in moments of drunken elitism one might even exclaim "how crass!". surely having fewer such chains is better, especially when the given alternative (to DTRT) is to be more precise and more explicit. that is the general problem of `eval-after-load', essentially, from a lazy maintainer's pov: it is overkill. anyway, that's how i see things. ymmv. thi