From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: relative load-file Date: Fri, 13 Nov 2009 11:17:51 -0500 Message-ID: References: <6cd6de210911110901v24307163i253e69e89c72c9e@mail.gmail.com> <6cd6de210911111701s5d5a989fp27386dd1379065ff@mail.gmail.com> <6cd6de210911111809j526ce8bfmcb5d57f907afff96@mail.gmail.com> <6cd6de210911120501u24047705w5caad5112db6cb45@mail.gmail.com> <6cd6de210911122034y9c3338epcf18a36a1cdf77b3@mail.gmail.com> <6cd6de210911130703o23c75d44y21ff9144c0533152@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258129101 28089 80.91.229.12 (13 Nov 2009 16:18:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2009 16:18:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rocky Bernstein Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 17:18:14 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 1N8yqf-0004vy-IN for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 17:18:09 +0100 Original-Received: from localhost ([127.0.0.1]:44424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8yqZ-0008Pj-Vz for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 11:18:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8yqU-0008P8-LU for emacs-devel@gnu.org; Fri, 13 Nov 2009 11:17:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8yqQ-0008Kj-8z for emacs-devel@gnu.org; Fri, 13 Nov 2009 11:17:58 -0500 Original-Received: from [199.232.76.173] (port=34928 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8yqQ-0008Kd-2k for emacs-devel@gnu.org; Fri, 13 Nov 2009 11:17:54 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37301 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8yqO-0003jG-Pm; Fri, 13 Nov 2009 11:17:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAFAV/UpFpYg5/2dsb2JhbACBTtRyhDwEiTY X-IronPort-AV: E=Sophos;i="4.44,738,1249272000"; d="scan'208";a="49364258" Original-Received: from 69-165-136-57.dsl.teksavvy.com (HELO pastel.home) ([69.165.136.57]) by ironport2-out.pppoe.ca with ESMTP; 13 Nov 2009 11:17:52 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id D96B17F82; Fri, 13 Nov 2009 11:17:51 -0500 (EST) In-Reply-To: <6cd6de210911130703o23c75d44y21ff9144c0533152@mail.gmail.com> (Rocky Bernstein's message of "Fri, 13 Nov 2009 10:03:37 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:116955 Archived-At: >> This example seems to fail the "those cases do show up" test. Not >> just because the requires/loads tend to occur early in an Elisp >> buffer, but also because a call to `find-file' (or set-buffer for >> that matter) at the top-level of an Elisp buffer is extremely rare >> and strongly discouraged by the convention that loading an Elisp file >> should not have any "visible effect" (this convention is >> useful/necessary to allow things like Customize to load files at >> will, e.g. just to get the needed info to build a customization >> buffer). > I see. You seem to have strong and somewhat self-fulfilling views of what > programmers should do or not do in Emacs. It's not restrictions about what programmers should do in Emacs, it's restrictions about how to structure an Elisp package: the file itself should be "declarative", such that the `load' itself won't affect the behavior of Emacs. This is a convention that doesn't come from me, but has appeared over the years as being useful. The example of `customize' is just one of them. Another case where we load a file and don't expect it to change the behavior of the running Emacs session is when you byte-compile a file that requires `foo': the byte-compiler should be free to load `foo' without having to worry about it changing the background color of the running session. Note also that it's a convention that most packages have always followed without even thinking about it. And the few packages that didn't follow it had no trouble adjusting. Stefan