From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: RE: always put Customizations in `custom-file', never in `user-init-file' Date: Tue, 11 Dec 2007 18:53:05 +0900 Message-ID: <87r6htd0ce.fsf@uwakimon.sk.tsukuba.ac.jp> 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 X-Trace: ger.gmane.org 1197366612 1692 80.91.229.12 (11 Dec 2007 09:50:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2007 09:50:12 +0000 (UTC) Cc: "Lennart Borgman \(gmail\)" , Emacs-Devel To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 10:50:22 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 1J21kp-0008Gc-Gq for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2007 10:50:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J21kX-0005pB-DK for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2007 04:50:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J21kQ-0005lK-SM for emacs-devel@gnu.org; Tue, 11 Dec 2007 04:49:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J21kK-0005bN-T7 for emacs-devel@gnu.org; Tue, 11 Dec 2007 04:49:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J21kK-0005b6-Nz for emacs-devel@gnu.org; Tue, 11 Dec 2007 04:49:48 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J21kK-0002u1-7U for emacs-devel@gnu.org; Tue, 11 Dec 2007 04:49:48 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (unknown [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6EA3C8003; Tue, 11 Dec 2007 18:49:45 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CF55211FA3F; Tue, 11 Dec 2007 18:53:05 +0900 (JST) In-Reply-To: X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" (+CVS-20070621) XEmacs Lucid X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:85032 Archived-At: Drew Adams writes: > > 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? (defvar user-init-directory (expand-filename "~/.xemacs")) (defvar user-init-file-basename "init.el") (defvar custom-file-basename "custom.el") or similar happen very early in the startup process, even before options processing. There's a bunch of compatibility cruft which checks for ~/.emacs and so on, but the basic idea is that there are standard places for these. There are options --user-init-directory (so I can do --user-init-directory=~drew/.xemacs and get your whole setup) and --user-init-file (for those with multiple personalities). Since our current custom.el policy is load-after-init-file, we don't have a command option to set that; you have to use a setq on custom-file in the init file. > - 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) All of these are supported by the XEmacs scheme, although the support for the third could be better. > 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. The difference is that you keep focusing on the case where the user wants to do something complicated, and optimizing for it. The presumption throughout has been "Emacs should not load customizations unless the user says to do so." This doesn't make a lot of sense IMO. The strategy that has been implemented in XEmacs is 1) if there is an init file, load it. 2) if there is a customizations file, load it. If you don't want XEmacs to do that for you (and that is quite reasonable), simply hide those files by giving them names that XEmacs doesn't know about. The only tricky part is getting `custom-file' set up so that Customize knows where to save its state. However, for the customizations file, your suggestion of using `require' to load it makes a lot of sense; to suppress automatic loading, just do `(provide 'custom-file)'. This can be done explicitly to suppress the customizations entirely, or implicitly in the customizations file as you suggest. > 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? Yes. > 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). AIUI, that is not backward compatible: if custom-file is nil, Customizations currently get saved to the user's init file. If that's not true, then setting it to nil is fine. > In any case, I think (?) we agree now that Customize need never write > (load-file custom-file) to the init file. It should never do that (except on explicit user request). > I guess maybe you're saying that the custom file should always be loaded > automatically, after the init file, but I can't tell. Yes. As I say, there are use cases for loading it before the init file, but that can be handled with an explicit load. > 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 would work. > 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? This is in the context of the code which will try to load custom-file before the init file, and if not loaded by then, try to load it afterward. The idea is that the "before" customization file must have the default name, or Emacs can't find it. Then you tell Emacs what its name is by setq'ing custom-file, and it finds it at the after stage. > 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. Sort of. `custom-file' should be initialized to the default. The user can still explicitly set it to nil, and behavior should be backward compatible. > - 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?). No. Having the init file be the customizations file is a very bad idea IMO, but code that tries to enforce it is a waste of space. "ln -s .emacs .emacs.customizations", for starters. > - 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. Yes. (We've never had a request for such a command-line option.) > - At startup, .emacs is loaded, if it exists. Yes. > - 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. Yes, except that as above I would not bother with the check for the init file being different from the customizations file. Also, I would initialize `custom-file' to the default, making the "otherwise" clause unnecessary.