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: Tue, 14 Dec 2004 20:51:20 -0600 (CST) Message-ID: <200412150251.iBF2pKb10852@raven.dms.auburn.edu> References: <200412140150.iBE1oTY02196@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1103079686 11648 80.91.229.6 (15 Dec 2004 03:01:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Dec 2004 03:01:26 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 15 04:01:18 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 1CePPh-0000rD-00 for ; Wed, 15 Dec 2004 04:01:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CePZr-0005rP-IO for ged-emacs-devel@m.gmane.org; Tue, 14 Dec 2004 22:11:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CePYl-0005P3-7V for emacs-devel@gnu.org; Tue, 14 Dec 2004 22:10:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CePYe-0005Lm-CE for emacs-devel@gnu.org; Tue, 14 Dec 2004 22:10:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CePYd-0005K6-Ga for emacs-devel@gnu.org; Tue, 14 Dec 2004 22:10:31 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CePI7-0002xv-Qp; Tue, 14 Dec 2004 21:53:28 -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 iBF2rLFu021512; Tue, 14 Dec 2004 20:53:21 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id iBF2pKb10852; Tue, 14 Dec 2004 20:51:20 -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 Tue, 14 Dec 2004 18:20: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:31135 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31135 Richard Stallman wrote: A small amount of incompatibility in something unusual and advanced like this is no big deal. If I understand your proposal correctly, if the user has a non-nil custom file, nothing changes compared to 21.3. The file will no longer be automatically loaded after .emacs as in current CVS, but that did not happen in 21.3 anyway. So the only problem concerns the case where custom-file is nil. If custom-file is nil, the user currently expects Custom to write exclusively into .emacs. All current packages the user is using expect that. Here is a very concrete example where your proposed change could cause trouble. From initsplit.el (not included with the Emacs distribution but used by some people): ;; Note that that you *must* load each file that contains your various ;; customizations from your .emacs. Otherwise, the variables won't ;; all be set, and the next time you use the customize interface, it ;; will delete the settings in those other files. You are going to save in the last of those files, which are written in some random order. If I understand correctly, with custom-file being nil, initsplit is watching .emacs for customizations being written in there, to delete them from .emacs and put them in the correct (according to the user) files. Even if by some miracle your proposed changes would not break initsplit, they are likely to break other similar packages. Second scenario where your changes could cause trouble: The user may load several files with `custom-set-variables' forms to add a set of customizations to his .emacs. Then he just nominally saves some option using Custom to make Custom write all the stuff into .emacs. So you save everything in the last file he loaded. I hope he notices before he deletes that file. I also hope that he does not use that file for other purposes. I understand the reasons for no longer automatically loading custom-file after .emacs. I understand the reasons for removing the defcustom. I do not understand what problems would remain after that. Sincerely, Luc.