From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: New tack for Customize Date: Tue, 8 Feb 2005 12:38:26 -0800 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1107896169 10501 80.91.229.2 (8 Feb 2005 20:56:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2005 20:56:09 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 08 21:56:09 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CycOh-0002iH-3U for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 21:55:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cycd5-0004hL-N0 for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 16:10:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CycUe-00014g-4J for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CycUL-0000wS-OS for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:43 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CycUL-0000rS-17 for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:37 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Cyc7z-00042z-Eu for emacs-devel@gnu.org; Tue, 08 Feb 2005 15:38:31 -0500 Original-Received: from rgminet01.oracle.com (localhost [127.0.0.1]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j18KcUus030365 for ; Tue, 8 Feb 2005 15:38:30 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j18KcUbP030356 for ; Tue, 8 Feb 2005 15:38:30 -0500 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j18KcTQP028404 for ; Tue, 8 Feb 2005 13:38:29 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-66-208.vpn.oracle.com [141.144.66.208]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j18KcSvc028392 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 8 Feb 2005 13:38:29 -0700 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33094 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33094 Let's consider a new tack. (See also my reply to RMS, Changed outside --> set, in Customize UI.) Summary: a) .emacs 1) establishes baseline (unchanged) option values and 2) can specify the use of individual standard values. b) All option changes after startup load are consider to "set" the option. c) We still have to fix the bugs. Details: 1. We fix the bugs having to do with list variables that should not be simply setq'd by Customize, as Luc has pointed out. We make Customize somehow able to deal with such lists, or we remove them from Customize, or we find some other solution. 2. We get rid of any changes to user options by vanilla Emacs after the custom file (.emacs) is read. I'm thinking of `user-mail-address' here. We manage to make `custom-set-variables' always be the last thing executed upon startup. 3. The custom file and all that it loads are considered, for a given user, to set the personal baseline, "unchanged" values of user options it affects. No matter how they are set during the load process, all option values set during startup load are marked initially in Customize as unchanged, or "Custom File", values. This corresponds to today's label "option has been set and saved". These values are not necessarily the same as the `standard' (= defcustom default) values. They calibrate Customize for a particular user, defining the zero point against which all subsequent changes are compared. All option values that have not been changed by startup load are marked in Customize as "Standard". So, after startup, Customize has only "Custom File" values and "Standard" values. The former were set during startup but are henceforth considered unchanged; the latter were not set during startup. 4. This means that not all such baseline values are saved values in the sense of being explicitly listed in `custom-set-variables'. They are, however, all saved in the sense that the custom file and the files it loads are _persistent_, and reloading them will reestablish these personal baseline values. 5. Subsequent to startup load, _all_ changes to user options, no matter how they are made, are marked in Customize as "Set". 6. In Customize, you can Get standard values or current values, filling the edit fields. This does not also set the current value - you must use Set to do that. 7. We might also make it possible to Get some baseline values - those that are explicitly saved in `custom-set-variables'. 8. Getting other baseline values, that is, those that are set in libraries loaded during startup, would not be possible generally. Some of these might be resettable (changing not just the edit field but also the current value) by reloading the appropriate library, if we can devise a good way to keep track of the library (e.g. `load-history'). It may not, however, be a good idea to even try to get or reset such options. 9. If you try to Save a value, and that value is the same as the `standard' value for the option, a dialog makes you choose whether you want to save the edited value (= standard) or you want to specify, in your custom file, that the `standard' value that is current during startup should be used. 10. The latter corresponds more or less with today's Erase Customization. If you choose it, however, no analysis of your custom file is done, and no customization is removed from it. Instead, an entry `(foo-option standard)' is added to `custom-set-variables', which is at the end of the custom file. Such an entry, when read on startup, is interpreted to DTRT: set option `foo-option' to its standard value and mark its value in Customize as "Standard" (not "Custom File"). This means that any customization of `foo-option' that you might do somewhere during startup is overridden by your declaration to use the standard value. And any future change to the standard value (e.g. bug fix) is correctly picked up. I think this approach would work and would be intuitive. It might even provide some help wrt some of the more minor problems. Library changes to user options, if always loaded during startup, will simply be reflected as being part of the baseline (pseudo-saved) personal values. In some (minor) cases, that might be a sufficient temporary "fix". For example, that would reflect the `baud-rate' option setting as a baseline value instead of reflecting it properly as a `standard' value, but at least it would not show up as a user change (either changed outside or set inside). (Obviously, this is for after the release.)