From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Documentation for custom-file - is not (load custom-file) needed? Date: Sun, 12 Dec 2004 21:49:22 -0600 (CST) Message-ID: <200412130349.iBD3nMQ21137@raven.dms.auburn.edu> References: <075b01c4d9a4$52799460$0200a8c0@sedrcw11488> <00bb01c4daee$5eb81350$0200a8c0@sedrcw11488> <200412051733.iB5HXIX13206@raven.dms.auburn.edu> <000001c4db1a$8d3770f0$0200a8c0@sedrcw11488> <200412060046.iB60kZj15003@raven.dms.auburn.edu> <003e01c4db31$e45a2550$0200a8c0@sedrcw11488> <200412060402.iB6421q15173@raven.dms.auburn.edu> <200412070539.iB75dV924747@raven.dms.auburn.edu> <200412090220.iB92KHR16407@raven.dms.auburn.edu> <874qiusno3.fsf@jurta.org> <00d101c4ded0$37cad4e0$0200a8c0@sedrcw11488> <87653am6wd.fsf-monnier+emacs@gnu.org> <00e301c4dee7$283b19b0$0200a8c0@sedrcw11488> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1102909896 26986 80.91.229.6 (13 Dec 2004 03:51:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 13 Dec 2004 03:51:36 +0000 (UTC) Cc: juri@jurta.org, lennart.borgman.073@student.lu.se, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 13 04:51:29 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CdhFB-0002EQ-00 for ; Mon, 13 Dec 2004 04:51:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CdhPF-0001vf-LI for ged-emacs-devel@m.gmane.org; Sun, 12 Dec 2004 23:01:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CdhP9-0001vW-KO for emacs-devel@gnu.org; Sun, 12 Dec 2004 23:01:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CdhP8-0001ux-R0 for emacs-devel@gnu.org; Sun, 12 Dec 2004 23:01:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CdhP8-0001uu-Oi for emacs-devel@gnu.org; Sun, 12 Dec 2004 23:01:46 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CdhF2-0001jp-NP for emacs-devel@gnu.org; Sun, 12 Dec 2004 22:51:20 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id iBD3pJFu004098; Sun, 12 Dec 2004 21:51:20 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id iBD3nMQ21137; Sun, 12 Dec 2004 21:49:22 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@iro.umontreal.ca In-reply-to: (message from Stefan Monnier on Fri, 10 Dec 2004 15:40:56 -0500) 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: main.gmane.org gmane.emacs.devel:31054 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31054 As I already said, the proposed solutions for custom-file seemed to be getting too complex. I believe the best solution is to leave custom-file (essentially) unchanged with some documentation changes. Note that the main use of custom-file is to have different custom files for different versions of Emacs. If we implement a completely new way of doing things, then we make things more complicated for the user, who will have to learn both methods, as well as how to make them coexist. I would recommend that most users customize custom-file with a setq in their .emacs. Customizing through Custom has several pitfalls, _even_ if only done only for the current session, but can be handy for certain types of uses of `custom-file' if the user is willing to read some documentation. We should clearly warn the user if the user selects `File' in the Custom buffer, and there are various relatively easy ways (built into Custom) to do so. With proper warning and documentation, there is no need to eliminate the possibility of customizing through Custom. I have various concrete ideas in mind, but it would be easier to implement them than to explain the details without implementation. I would have to experiment a little bit to see how things really look in practice in a real customization buffer. Basically, the docstring would be slightly expanded and changed and the appearance of the Custom buffer would change, if `File' is selected, with a warning appearing, saying: maybe you would rather customize this through .emacs. If you really want to do it through Custom, read the docs. The only (small) non-documentation change needed would be connected with the following pointed out by Juri: 5. All these changes should be made before the next release to be able to fix a problem in startup.el. The problem is the following: When `custom-file' (which has an absolute file name) is not literally equal to the name of the loaded customization file, e.g. in the following configuration: (setq custom-file "~/emacs/lisp/custom-21.4.el") (load "custom-21.4.el") then custom-21.4.el is loaded twice. startup.el fails to see that it is already loaded, since it expects exactly the same absolute file name in `load-history' which is not the case. Instead of that, it should check the value of a new variable which is set to `load-file-name' during loading of the file with `custom-file-loaded'. One solution might be to tell the user who customizes in .emacs and for some reason needs to load the file in .emacs instead of after it, to do: (setq custom-file "~/emacs/lisp/custom-21.4.el") (load custom-file) and _not_ do what is done in the quote above. For the user customizing through Custom, Stefan's code could check for a saved-value property on `custom-file'. If there is such a property, `custom-file' has been loaded, even if it appears not to be (for the reason given in the above quote). This would be the only (very minor) code change. I could submit a concrete implementation within the next week or so, if people would agree that the above is worth a try. Sincerely, Luc.