From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: always put Customizations in `custom-file', never in `user-init-file' Date: Mon, 10 Dec 2007 16:47:41 -0800 Message-ID: References: <87zlwicdwk.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1197334166 21530 80.91.229.12 (11 Dec 2007 00:49:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2007 00:49:26 +0000 (UTC) Cc: "Lennart Borgman \(gmail\)" , Emacs-Devel To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 01:49:35 2007 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 1J1tJG-00031U-N7 for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2007 01:49:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1tIz-0005ev-2f for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2007 19:49:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J1tIv-0005el-G0 for emacs-devel@gnu.org; Mon, 10 Dec 2007 19:48:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J1tIt-0005eJ-JC for emacs-devel@gnu.org; Mon, 10 Dec 2007 19:48:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1tIt-0005eG-FP for emacs-devel@gnu.org; Mon, 10 Dec 2007 19:48:55 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J1tIt-0002a3-5I for emacs-devel@gnu.org; Mon, 10 Dec 2007 19:48:55 -0500 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lBB0mmuf006893; Mon, 10 Dec 2007 17:48:48 -0700 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id lBAKZ237018700; Mon, 10 Dec 2007 17:48:47 -0700 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt351.oracle.com with ESMTP id 3428259161197334056; Mon, 10 Dec 2007 16:47:36 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87zlwicdwk.fsf@uwakimon.sk.tsukuba.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:85017 Archived-At: > > In any case, IIUYC, users should be able to do whatever they > > like in the new situation also, because it would only load > > `custom-file' upon explicit request, never automatically. > > Our experience is that there are a lot of users who do fine with *no* > *init file* *at all*. Use of Customization should not depend on the > presence of an init file, and even one pair of parentheses is enough > to scare some users. Not sure I understand. Currently, if a user doesn't have an init file, then s?he can use Customize but s?he cannot save Customize customizations. That would not change with what I propose. And if s?he doesn't try to save Customize customizations, then she still need not have an init file. If a user wants to save Customize customizations, then s?he will need both files in my proposal, whereas s?he currently needs only an init file. We should, in any case, make it easy for a user, after using Customize (but not being able to save, because no files), to create an init file that contains (load-file custom-file) - but see also below. And we should give the user a chance to specify the files to use for `user-init-file' and `custom-file'. > > Users need to be able to control when Customizations get loaded. I, for > > example, load `custom-file' last, at the end of my .emacs. > > Others load it first. Still others load it somewhere in the middle. > > There should be no automatic loading of `custom-file'. > > Our experience says that automatic "after" loading is fine > for 99% of users I suppose that we could adopt the convention that if `custom-file' was not loaded by the init file (or by any files it loaded), but variable `custom-file' is defined at the end of this loading, then `custom-file' would be loaded at that time. Another approach would be to display a warning at the end of init file loading that `custom-file' was defined but never loaded. That's perhaps a bit of a cop-out. Customize should in any case not add (load-file custom-file) to the init file automatically, except possibly when the init file is empty. The user might instead have (load-file custom-file) in some other file (that is loaded) - Customize should not assume anything about where/when `custom-file' is loaded. > (that's all we actually provide in a released version), and that > "before" is satisfactory for the rest. (There may be users we haven't > encountered who *need* finer control, but the fact that in the 7 years > since December 2000 we haven't encountered *one* suggests there are > very few.) That sounds about right to me. But there is no reason not to give users the flexibility to control when `custom-file' is loaded, is there? > The reason I suggest providing the "before" option is that > I know there are use cases for it. I have never heard of anybody who > *needed* it loaded in the middle of the init file. I *have* helped > debug problems that happened because customizations were loaded in the > middle of the init file rather than at the appropriate end, though. Again, that all sounds right to me. Are you suggesting having an explicit option for this, with `before' and `after' values? That has the advantage that it obviates needing to put (load-file custom-file) in the init file. On the other hand, it loses some flexibility - you might want to load `custom-file' after some event, or in some situation but not in others, or after loading some feature, or... Granted, it might be that few users would need or want that flexibility, but why not allow it? A better possibility would be to have option values `before', `after', and nil, with the latter meaning no automatic loading - the user could still use an explicit (load-file custom-file). Of course, there might be a problem for Emacs to try to know the value of that option without having yet loaded `custom-file'... ;-) Back to editing the init file, no? Or to having Customize put something in the init file to say when `custom-file' should be loaded... Neither of which would help those users you mention who want saved customizations but no init file. Overall, I think (so far) the best solution is for users to put (load-file custom-file) in their init files, and to help them do that when they first try to save Customize settings, and to help them migrate from an existing init file that contains Customize settings. At the end of the day, in my view, a user would have either no init file and no custom file or both. And the init file would contain (load-file custom-file) somewhere (with a comment), or else the custom file would not get loaded (or it could be loaded at init end, as mentioned above). BTW, it might also be worth putting something at the beginning of the custom file to detect its being loaded more than once - perhaps raise an error in that case.