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: RE: Customize buttons that change user'scustomfileshouldaskforconfirmation Date: Mon, 7 Feb 2005 09:28:02 -0800 Message-ID: References: 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 1107798473 27548 80.91.229.2 (7 Feb 2005 17:47:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2005 17:47:53 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 07 18:47:53 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CyCz6-0000zt-4N for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2005 18:47:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyDDG-0002n9-Jd for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2005 13:02:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CyD9M-0001VJ-8l for emacs-devel@gnu.org; Mon, 07 Feb 2005 12:58:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CyD9I-0001U2-BM for emacs-devel@gnu.org; Mon, 07 Feb 2005 12:58:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyD91-00015a-2l for emacs-devel@gnu.org; Mon, 07 Feb 2005 12:57:55 -0500 Original-Received: from [141.146.126.231] (helo=agminet04.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CyCgB-0006Vz-NN for emacs-devel@gnu.org; Mon, 07 Feb 2005 12:28:08 -0500 Original-Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j17HS5Ht013582; Mon, 7 Feb 2005 09:28:05 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j17HS4XW013556; Mon, 7 Feb 2005 09:28:04 -0800 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 j17HS3du017828; Mon, 7 Feb 2005 10:28:03 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j17HS2lE017818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Feb 2005 10:28:03 -0700 Original-To: "Lennart Borgman" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: 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:33029 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33029 If we do split Erase Customization in two: a) "Get All" > "Standard" plus b) "Save All", then there is the question of how "Save All" should act wrt values in the buffer that happen to be the same as the standard values. Two possibilities: 1. Save is smart wrt `standard', recognizes equality between standard values and values to be "saved", and reworks the user's custom file much as Erase Customization does today. 2. Save is dumb, and always saves the values (edit fields) in the buffer to the user's custom file. It is the difference between a pointer and a copy: The meaning of #1 is to maintain the standard value in future sessions. Instead of a copy of the current `standard' value being saved, what would really be saved is an indication that the `standard' value is to be used - whatever the current standard value is at the time `custom-set-variables' is executed. (We will need to fix some of the pbs already discussed, before this will work correctly.) The meaning of #2 is to take a snapshot of the current `standard' values (those in the buffer) and save those value copies to the custom file. When I made the suggestion to split Erase Customization, I had #1 in mind (smart save, that is, no change to the Erase Customization behavior), but now I think that this should perhaps be a user choice, possibly on a case-by-case basis. A user might well somtimes want to Get the Standard value and then save that value, whether or not it happens to stay the `standard'. For save operations on multiple options (Save All button and menu item), we could provide radio buttons for the two choices in the buffer (or in the menu). For save operations on a single option, we could provide two different menu items. OTOH, it might be confusing to combine these two notions under the name "Save" - #2 is not at all a Save operation, in fact. With this consideration, perhaps "Save" should mean save, and we should have a separate button/item called something like "All Standard from Now On". Yes, this is a return to Erase Customization, I guess. What do others think?