From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: RE: eval-after-load not harmful after all (Was: Re: Why js-2mode?) Date: Tue, 11 Aug 2009 23:06:40 +0900 Message-ID: <87y6pq8mxb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <7b501d5c0908091634ndfba631vd9db6502db301097@mail.gmail.com> <998B83F771474211A37D1E2B6A497B61@us.oracle.com> <878whr9o4c.fsf@uwakimon.sk.tsukuba.ac.jp> <0AE832B5AEFE4453BB3E46F20DA29DE8@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1249999127 15248 80.91.229.12 (11 Aug 2009 13:58:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2009 13:58:47 +0000 (UTC) Cc: 'CHENG Gao' , 'Carsten Dominik' , 'Daniel Colascione' , 'Leo' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 11 15:58:39 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Marrz-00069z-Rv for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 15:58:32 +0200 Original-Received: from localhost ([127.0.0.1]:46668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Marry-0000yE-Gm for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 09:58:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Marru-0000y2-H2 for emacs-devel@gnu.org; Tue, 11 Aug 2009 09:58:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Marrp-0000xo-GR for emacs-devel@gnu.org; Tue, 11 Aug 2009 09:58:25 -0400 Original-Received: from [199.232.76.173] (port=58693 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Marrp-0000xl-BU for emacs-devel@gnu.org; Tue, 11 Aug 2009 09:58:21 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:47435) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Marro-0004JZ-BO for emacs-devel@gnu.org; Tue, 11 Aug 2009 09:58:20 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id A9F9A1535AC; Tue, 11 Aug 2009 22:58:17 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A638C1A27DB; Tue, 11 Aug 2009 23:06:40 +0900 (JST) In-Reply-To: <0AE832B5AEFE4453BB3E46F20DA29DE8@us.oracle.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 5bbff3553494+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 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:114049 Archived-At: Drew Adams writes: > sjt wrote: > > I note that all the advocates of e-a-l are package maintainers and UI > > types; all the deprecators are core. This is an inherent tension, and > > I think it should be resolved in favor of protecting the core. > > Nothing wrong with "protecting the core". > > The discussion was about the Elisp manual, whose target audience is > not just maintainers of the Emacs core. The help and guidance there > are used by a variety of programmer-users. > > Again, there's nothing wrong with (a) giving a general guideline, > and also (b) explaining the issues and giving additional info about > contexts where the guideline might not be something you would want > to follow. Yes, there is. If the manual says "use this feature only when appropriate," people with a biased view of Emacs (ie, my-package-centric, as opposed to core-centric) are naturally going to overuse the feature. IMO, it's worth leaning against the wind by documenting the semantics of the feature and the caution against using it in the core, perhaps with a gloss like "since in the core we can usually change both libraries to cooperate more closely". Those who really want to use the feature will do so anyway, or ask here. Note that all of the examples given so far of "why I would want to use eval-after-load" have been pretty dubious, so there's no positive "you might want to use `eval-after-load' when ..." advice to offer anyway.