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: Mon, 13 Dec 2004 19:50:29 -0600 (CST) Message-ID: <200412140150.iBE1oTY02196@raven.dms.auburn.edu> References: NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1102989289 11851 80.91.229.6 (14 Dec 2004 01:54:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 14 Dec 2004 01:54:49 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 14 02:54:39 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 1Ce1tf-0003Fr-00 for ; Tue, 14 Dec 2004 02:54:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Ce23m-0003Ks-Pr for ged-emacs-devel@m.gmane.org; Mon, 13 Dec 2004 21:05:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Ce23c-0003Kb-F9 for emacs-devel@gnu.org; Mon, 13 Dec 2004 21:04:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Ce23Z-0003Jh-RS for emacs-devel@gnu.org; Mon, 13 Dec 2004 21:04:54 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Ce23Z-0003JX-KN for emacs-devel@gnu.org; Mon, 13 Dec 2004 21:04:53 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ce1re-0002er-Ip; Mon, 13 Dec 2004 20:52:34 -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 iBE1qSFu011604; Mon, 13 Dec 2004 19:52:28 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id iBE1oTY02196; Mon, 13 Dec 2004 19:50:29 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Mon, 13 Dec 2004 14:51:17 -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:31092 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31092 I still do not see any benefit in all this complexity. What is wrong with: (setq custom-file ...) (load ...) in .emacs? This is what worked in the past and still works now. The only thing wrong with it that has been pointed out to me are problems caused by the automatic loading of `custom-file' after .emacs. You plan to eliminate that feature (something I agree with), thereby solving those problems. The second problem with the current situation is that customizing through Custom might mislead some users. You plan to eliminate the defcustom, which solves that problem. Which problems are left? The proposed solution could cause non-trivial trouble for unsuspecting users, who are in danger of having several files clobbered behind their back before they notice or understand the problem (see below). Details: 2. We should eliminate loading custom-file on startup. We should tell users that .emacs should load the appropriate file where custom values are stored. I completely agree that it is better to revert the automatic loading of custom-file after the loading of .emacs. This simplifies things and restores backward compatibility with prior released versions. Indeed, setting custom-file means only one thing: that the user wants Custom to write into that file. If the user wants in addition to load that file, he can do so. 1. We should eliminate custom-file as a defcustom. I do not really disagree with removing the defcustom. It breaks backward compatibility to a degree, but on the other hand. it simplifies things. It is relatively easy for the user who (like me) used Custom in the past to adapt. 3. Calling custom-set-variables in a file should add that file to a list of files that have done so. 4. Evaluating a custom-set-variables call in a buffer should not do any such thing. 5. When saving custom variables, if custom-file is set, save in that file. Otherwise, if they have only been loaded from one file, save in that file. Otherwise, if they have been loaded from more than one file, save in the most recently loaded such file. There are (at least) four things wrong with 2-5 above. Firstly, it adds complexity for no good reason. Secondly it breaks backward compatibility. Thirdly, it introduces a shaky temporary solution to something that is currently not really broken and for which we plan to implement a more solid alternative later on anyway (by 7.). Fourthly, and importantly, I believe it is wrong to clobber a user's file unless the user explicitly asked for Custom to write into that file by setting custom-file. People who use outside packages like initsplit may be in for quite a surprise and a lot of unexpected trouble with all their customization files getting clobbered one by one, before they notice the problem. This is way more serious than adding a trailing newline. 6. If the user wants to specify which file to save in, he can set custom-file or else just load that file. These are two different things. If the user wants to specify which file to save in, he can set custom-file. If he wants to load that file, he can load that file. 7. Eventually, in the future, we might figure out some clean UI for specifying which custom files to use and load under which conditions, and for moving definitions between them, but that is something for later. That would require a very careful rewrite of Custom. Sincerely, Luc.