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 11:20:40 +0900 Message-ID: <87sl2ac6pz.fsf@uwakimon.sk.tsukuba.ac.jp> 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 X-Trace: ger.gmane.org 1197339459 2229 80.91.229.12 (11 Dec 2007 02:17:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2007 02:17:39 +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 03:17:48 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 1J1ugt-00088l-HI for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2007 03:17:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1ugb-0000aG-LR for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2007 21:17:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J1ugX-0000Zg-Gm for emacs-devel@gnu.org; Mon, 10 Dec 2007 21:17:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J1ugW-0000Yj-1S for emacs-devel@gnu.org; Mon, 10 Dec 2007 21:17:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1ugV-0000YZ-Py for emacs-devel@gnu.org; Mon, 10 Dec 2007 21:17:23 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J1ugV-0001OT-AZ for emacs-devel@gnu.org; Mon, 10 Dec 2007 21:17:23 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (unknown [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id E948E1535A8; Tue, 11 Dec 2007 11:17:21 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 54A3C1A2E12; Tue, 11 Dec 2007 11:20:41 +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:85021 Archived-At: Drew Adams writes: > 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. > And we should give the user a chance to specify the files to use > for `user-init-file' and `custom-file'. 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. > 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? IMO, the unusual case is where custom-file exists but the user doesn't want it loaded at normal startup. 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. > 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! > > (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. ;;; 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))) 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. > 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. No. As you note, such an option would need to be a command-line option. Rather, 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")) 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). > 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? "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. ;-)