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 22:15:08 -0800 Message-ID: References: <87sl2ac6pz.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 1197353741 32718 80.91.229.12 (11 Dec 2007 06:15:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2007 06:15:41 +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 07:15:49 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 1J1yP9-0006S9-He for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2007 07:15:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1yOr-00058R-Gn for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2007 01:15:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J1yOk-00055J-S2 for emacs-devel@gnu.org; Tue, 11 Dec 2007 01:15:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J1yOj-000530-FT for emacs-devel@gnu.org; Tue, 11 Dec 2007 01:15:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1yOj-00052f-Ar for emacs-devel@gnu.org; Tue, 11 Dec 2007 01:15:17 -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 1J1yOi-0002K7-OM for emacs-devel@gnu.org; Tue, 11 Dec 2007 01:15:17 -0500 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lBB6FC6t001998; Mon, 10 Dec 2007 23:15:13 -0700 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lBB5n9q0019629; Mon, 10 Dec 2007 23:15:12 -0700 Original-Received: from 141.144.88.227 by acsmt350.oracle.com with ESMTP id 3429448411197353709; Mon, 10 Dec 2007 22:15:09 -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: <87sl2ac6pz.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:85028 Archived-At: > > 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. > > IIRC, in XEmacs, that was false: if you had no .emacs and tried to > save, Customize would create it for you. (Presumably after prompting.) > > > 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. > > Inelegant, and confusing to the user. How do you do it in XEmacs (after the migration)? I think you said that users can have a custom file without an init file. Where do they let Emacs know what file is their custom file? If they don't set `custom-file' in the init file, where is it set and read at startup? The most inelegant and most confusing is what we have now in GNU Emacs, IMO: mixing user hand customizations with Customize-generated code in a single file. We should move to a system of separate files for user editing and Customize. That's the first thing to define, including handling these cases: - a user who starts from scratch and doesn't know or care about Lisp - users who want to specify the location of their custom file - users who want to load the custom file at different times during startup, via an explicit (load-file custom-file) The question of migration is a separate question. We should first define the desired end state. > > And we should give the user a chance to specify the files to use > > for `user-init-file' and `custom-file'. I should have mentioned only `custom-file'. Variable `user-init-file' is not a user option, but you can specify the init file using a command-line option. > The kind of user who benefits from total automation doesn't *want* > that, and the kind of user who doesn't benefit doesn't *need* that. Please describe the "total automation". But see below; perhaps I've guessed it sufficiently. I'm one user who might not benefit from total automation (depending on what you mean), and I do want to specify my custom file location. (The Emacs manual, node Saving Customizations, gives an example of why a user might want to specify it.) > > 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. > > What do you have against customizations, that you're willing to go to > such lengths that nobody will ever accidently have their > customizations loaded? Huh? I don't have anything against customizations. What lengths do you think I'm going to? I don't understand your point here. What is the problem you see with what I suggested? I think it's the same thing Lennart suggested, which you said "certainly works": >> 1) load .emacs >> 2) if .emacs did not load custom-file then do that >> immediately after .emacs. > IMO, the unusual case is where custom-file > exists but the user doesn't want it loaded at normal startup. I don't disagree with that. > I think it's perfectly reasonable to have such users set > custom-file to a non-nil symbol and have Emacs compute > > (progn > (setq custom-file (or custom-file user-init-file)) > (when (and (stringp custom-file) > (file-readable-p custom-file)) > (load custom-file))) > > where it loads the custom-file. This is backwards compatible with the > current meaning of nil, and allows users to suppress loading of the > Customizations. I guess that is some proposed standard startup code (and not user code). I think you're saying that a user who for some reason doesn't want to load an existing custom file would set `custom-file' to a non-nil symbol, say `foobar', to avoid loading it. Is that right? I would have said that s?he would just set `custom-file' to nil: if the value doesn't name an existing file, then no custom file gets loaded (in GNU Emacs, but perhaps not in XEmacs). But why are we talking about this unusual case? Did you think I was referring to it? When/where would this code be executed? Would it run in addition to loading the init file or instead of that? Sorry, I don't really see your point. > > 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. > > I don't understand. Customize is about providing a hood-welded-shut > facility for customizations. Warranty is void if this seal is broken. > ALL FACES YOURS NOW OURS ARE. This is not a problem. setq works on > defcustoms, you know! I have no idea what you are talking about; sorry. My point was that Customize should not write (load-file custom-file) to the init file unless the latter is empty. The reason I gave is that the user might load it from another file (which is loaded ultimately from the init file). In any case, I think (?) we agree now that Customize need never write (load-file custom-file) to the init file. I guess maybe you're saying that the custom file should always be loaded automatically, after the init file, but I can't tell. Again, I personally have no problem with it being loaded automatically at the end, if it has not already been loaded. To prevent it being loaded more than once, the custom file could have (provide 'custom-file), and the startup sequence could do an implicit (require 'custom-file custom-file) at the end. That way, if it was already loaded (e.g. if a user put (load-file custom-file) at the beginning of .emacs) then it would not be reloaded. > > > (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? > > *shrug* It's theirs for the taking. The same after-init-hook hack > that currently allows the "before" users to put (load custom-file) at > the very top of their user-init-file allows them to put it anywhere > else they want, too. Then it sounds like we agree. You didn't mention such a hook hack before or say that the "before" treatment was in fact an "anywhere" treatment. You mentioned "the `before' option", so I thought the XEmacs startup did something specifically limited to loading custom file "before" init file. > ;;; load custom.el here, not after the init file > (load custom-file) > (setq custom-file-saved custom-file > custom-file nil) > (add-hook 'after-init-hook (lambda () (setq custom-file > custom-file-saved))) I guess you're saying that a XEmacs user does that to prevent multiple loads of the custom file (instead of using provide/require or some other way) - is that right? I have no real problem with that way or another way. > Of course the hacker who writes the support for automatic "after" > loading needs to ensure that after-init-hook is called *after* > custom-file would be loaded. I don't see a problem with using `require' and putting a `provide' in the custom file. But whatever works. > people who insist on "after" would rename their > custom-file---I used "~/.xemacs/after-init.el" when I was > experimenting---and put something like > (setq custom-file (expand-file-name "after-init.el" "~/.xemacs")) Sorry, but I'm really having trouble following you. That just sets `custom-file'. How does that change the before/after behavior? And which do you mean here by "insist on `after'"? Do you mean load custom file after init file or load init file after custom file? I guess you mean the former, but I can't tell. I thought that the "after" case was loading custom file after init, and that that was the default behavior ("99%") - so there would be nothing to "insist on". I thought that you didn't need to do anything to have the custom file loaded after the init file, and you needed to explicitly load the custom file in your init file to get it loaded before the (rest of the) init file. > in their user-init-file. This is preferable to automatic "after" > loading primarily because using after-init-hook looks more fragile, > and this has more robust failure modes (the custom.el-was-loaded flag > is managed by Emacs transparently to the user, so custom.el won't be > loaded twice unless the user does it explicitly). > > "Option overload" is not a good thing. Users who want to take the > flexibility can do so using standard functionality. Other users just > don't want to know, and I don't blame them. ;-) I think we agree, but I'm not sure. I think we're both saying that the custom file would be loaded after the init file automatically, unless it had already been loaded. I think you said that XEmacs users could, if they want, have only a custom file and not an init file, which is something I hadn't considered (it's not possible in GNU Emacs AFAIK). I assume that that means a custom file at the default location (or perhaps there is a command-line option also?). I don't have a problem with that. And I agree that it would be desirable for a user who doesn't care or want to edit Lisp to be able to simply do nothing and use only Customize. Is this something you would agree with: - Customize saves to the location specified by `custom-file' or to a default location if that option is nil. - Customize never writes to the init file. The custom file and the init file cannot be the same file. If the value of `custom-file' is .emacs (or the value of the init file from the command line), then it is ignored (and a warning is shown?). - A user can prevent loading an existing custom file by either setting `custom-file' to a non-nil symbol (your suggestion) or by using a command-line option. - At startup, .emacs is loaded, if it exists. - After loading .emacs (or instead of loading it, if it does not exist), the custom file is loaded, unless it has already been loaded. If the value of `custom-file' names an existing file (other than the init file), then that is loaded; otherwise, if the default custom file exists, then it is loaded. If the user has no init file, then the custom file must be at the default location. If you disagree but are otherwise in favor of getting rid of Customize stuff in the init file, please make a concrete proposal. You have valuable experience in this area; please contribute a proposal describing the end result and how to get there.