From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rocky Bernstein Newsgroups: gmane.emacs.devel Subject: Re: relative load-file Date: Fri, 13 Nov 2009 11:39:29 -0500 Message-ID: <6cd6de210911130839q275b4788p73d0dc77271bfb34@mail.gmail.com> References: <6cd6de210911110901v24307163i253e69e89c72c9e@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: multipart/alternative; boundary=001636b2bc83bf6f3e0478434d09 X-Trace: ger.gmane.org 1258130391 32394 80.91.229.12 (13 Nov 2009 16:39:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2009 16:39:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 17:39:43 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 1N8zBX-0006jq-Bw for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 17:39:43 +0100 Original-Received: from localhost ([127.0.0.1]:56110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8zBW-0003Mm-Qp for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 11:39:42 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8zBP-0003L5-Rm for emacs-devel@gnu.org; Fri, 13 Nov 2009 11:39:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8zBK-0003GG-TZ for emacs-devel@gnu.org; Fri, 13 Nov 2009 11:39:35 -0500 Original-Received: from [199.232.76.173] (port=42913 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8zBK-0003G4-Mu for emacs-devel@gnu.org; Fri, 13 Nov 2009 11:39:30 -0500 Original-Received: from mail-pw0-f47.google.com ([209.85.160.47]:42847) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8zBK-0007Gx-7F for emacs-devel@gnu.org; Fri, 13 Nov 2009 11:39:30 -0500 Original-Received: by pwi9 with SMTP id 9so2216270pwi.26 for ; Fri, 13 Nov 2009 08:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=H1jhmmkzNjFwyBCTjR5LqadZMSOLNcXClOgBbp+xfxU=; b=NEqPaCRfPljN56N3TRZW1sFGGJiq40xSpJlzT6QsXNa99fECSUmc2muYMPpe3khfjn wNHl0ytLIHShLVTODdGjynFe63npF1wecAKuzOHtQL5eaxypDOdk4u8oSm9Mnmd+8F5Y iDlGdo6TCNhqsG0LnhyV5HQt8yE0GcVGipRkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=DoFIh0txsNnspqDDxSAuqm04Q1YCmJ5EBGxp7tqojwwHvpBoRQanLGpZpVclLDnlys u7kTZrsoSyaI02xpI2T5x0mr2JVHk8GUzSfSb/Y+IPCgU5eNt422rOb+r9TxBpIaR5nA YDnSXkF5R+mKDbbZvplH/TIANwdbxG9PzgyIU= Original-Received: by 10.142.55.11 with SMTP id d11mr353722wfa.334.1258130369375; Fri, 13 Nov 2009 08:39:29 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 7f2f7b105ea711b0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:116956 Archived-At: --001636b2bc83bf6f3e0478434d09 Content-Type: text/plain; charset=ISO-8859-1 Ok. Thanks yet again for the useful information. I imagine this is documented elsewhere as well. When given the choice of writing code that works when conventions are followed and code that works independent of whether conventions are followed, I'll choose the later, even though I myself will try to follow convention. (Except of course, there is good reason not to). On Fri, Nov 13, 2009 at 11:17 AM, Stefan Monnier wrote: > >> 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 > --001636b2bc83bf6f3e0478434d09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok. Thanks yet again for the useful information. I imagine this is document= ed elsewhere as well.

When given the choice of writing code that wor= ks when conventions are followed and code that works independent of whether= conventions are followed, I'll choose the later, even though I myself = will try to follow convention. (Except of course, there is good reason not = to).


On Fri, Nov 13, 2009 at 11:17 AM, Stefan= Monnier <= monnier@iro.umontreal.ca> wrote:
>> 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 f= ile
>> 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. =A0You seem to have strong and somewhat self-fulfilling views o= f 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. =A0The example of `customize' is just one of them. =A0Another 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 followe= d
without even thinking about it. =A0And the few packages that didn't fol= low
it had no trouble adjusting.


=A0 =A0 =A0 =A0Stefan

--001636b2bc83bf6f3e0478434d09--