From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: eval-after-load not harmful after all (Was: Re: Why js-2mode?) Date: Mon, 10 Aug 2009 11:21:32 -0400 Message-ID: References: <7b501d5c0908091634ndfba631vd9db6502db301097@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1249918329 5766 80.91.229.12 (10 Aug 2009 15:32:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2009 15:32:09 +0000 (UTC) Cc: Carsten Dominik , emacs-devel@gnu.org, CHENG Gao To: Leo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 10 17:32:01 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 1MaWqu-000889-Sq for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2009 17:32:01 +0200 Original-Received: from localhost ([127.0.0.1]:58714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaWqt-0003Ct-RG for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2009 11:31:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaWgw-0001O4-Ko for emacs-devel@gnu.org; Mon, 10 Aug 2009 11:21:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaWgs-0001I7-PF for emacs-devel@gnu.org; Mon, 10 Aug 2009 11:21:42 -0400 Original-Received: from [199.232.76.173] (port=42068 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaWgs-0001Hv-GK for emacs-devel@gnu.org; Mon, 10 Aug 2009 11:21:38 -0400 Original-Received: from vpn.merrillpress.com ([64.61.107.78]:58792) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MaWgs-0007xY-2p for emacs-devel@gnu.org; Mon, 10 Aug 2009 11:21:38 -0400 Original-Received: from cpe-67-246-181-235.buffalo.res.rr.com ([67.246.181.235] helo=[192.168.1.103]) by mars.merrillpress.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1MaWgn-0001Kv-R7; Mon, 10 Aug 2009 11:21:34 -0400 In-Reply-To: X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:113974 Archived-At: On Aug 10, 2009, at 5:26 AM, Leo wrote: > On 2009-08-10 09:54 +0100, CHENG Gao wrote: > ,----[ (info "(elisp)Coding Conventions") ] > | * Avoid using `eval-after-load' in libraries and packages (*note > | Hooks for Loading::). 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 a way that's not > | visible in that file. This is an obstacle for debugging, much > | like advising a function in the other package. Actually, I think the use of eval-after-load can be a *good* thing. As other people have mentioned, sometimes the author of a mode would like to add support to some other mode that provides a certain feature, e.g., hideshow. Requiring that rarely-used feature mode is inefficient, so what seems to happen in practice is that these feature mdoes grow lists of major modes with which they word. Consider hs- minor-mode, which by default has c-mode, c++-mode, bibtex-mode, and java-mode, or speeedbar's speedbar-obj-alist. The problem is that these lists are seldom updated, and more importantly, cannot really be exhaustive. In fact, these lists are a blatant layering violation, because lower-level functions like hideshow should not be required to know anything in particular about C. It's not really reasonable to expect the user to fill in the gaps. There are too many of them (the number of modes times the number of additional feature modes), and the user might not know enough to be able to customize the feature mode appropriately. eval-after-load provides a perfect solution. If foo-mode can detect that hideshow has been loaded, it can customize hideshow to handle foo primitives appropriately --- after all, it's foo-mode --- and still not incur the overhead of loading hideshow every time. (Also, hideshow doesn't need to be patched to add support for foo.) Granted, eval-after-load does have the potential to enable spooky action at a distance and make code hard to understand. But I don't think that fear is relevant when eval-after-load forms call functions specifically designed to be used by third parties to add support for a new environment of some sort. I think the coding convention should be revised.