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's customfileshouldaskforconfirmation Date: Tue, 8 Feb 2005 12:37:58 -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 1107895861 9491 80.91.229.2 (8 Feb 2005 20:51:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2005 20:51:01 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 08 21:51:00 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CycIe-0001Rt-JV for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 21:49:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CycUy-00016z-8h for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 16:02:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CycUJ-0000vo-IJ for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CycUD-0000rc-WF for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CycUD-0000rS-TV for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:29 -0500 Original-Received: from [148.87.122.33] (helo=rgminet04.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CycH8-0004hD-2A; Tue, 08 Feb 2005 15:47:58 -0500 Original-Received: from rgminet04.oracle.com (localhost [127.0.0.1]) by rgminet04.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j18Klu8L011595; Tue, 8 Feb 2005 15:47:56 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by rgminet04.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j18Kc2dW003103; Tue, 8 Feb 2005 15:42:35 -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 j18Kc1Bx028136; Tue, 8 Feb 2005 13:38:01 -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 j18Kc0pV028129 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 8 Feb 2005 13:38:00 -0700 Original-To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: 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:33092 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33092 "F => C", and then (sometime later) sets option Y on the same page, and then does "F => C,S", the effect is that the change to X is also saved. This may be highly confusing to a user. Good point. We need to somehow make crystal clear that the buttons and menubar menu items apply to _each_ option in the buffer. Possible ways include 1) using the word "All" in menu and button names and 2) asking for confirmation, warning that _all_ options are concerned. It could display the list of options that will be saved, and ask for confirmation, much as Dired does when you operate on marked files. Yes, why not. Clear All is not the right name for this, in any case. The term "Clear" commonly refers to merely emptying an edit field. We don't have such an operation (and we don't need it) - the closest operation we have is what you are calling Cancel. Cancel and "Clear All" will be confused. I'm not sure what you have in mind for this operation to do. Could you say? Clear All was from Kim's message: The button first asks the user for confirmation. If ok it does "D => F" (does not update C or S). It then prints a message Remember to use or to activate/save the values. IOW, it does Get Standard. C => F (Reset from Current) S => F (Reset from Saved) D => F (Reset from Standard) Using the combined Reset buttons would mean we have only Set, Save, and Reset. Any reset action should display a feedback message saying 1) that (all) the _edit fields_ have been reset from and 2) you can _set_ the current values to these fields with Set. I wouldn't use the term "reset" for these. Agreed. In a later mail (2/6), I proposed this (adopting Miles's suggestion of Get): Set All (F => C) Save All (F => C,S) Get All Standard (D => F) Saved (S => F) Current (C => F) 1. Each button name includes "All". Likewise for menu-bar menu items. 2. The "resetting" actions only fill the edit field; they do not set the current value. 3. The "resetting" actions are combined in a button menu (pulldown list). I am not sure whether the change from S => F,C into S => F is a good idea. Agreed. See proposal above. I still believe "Erase" is needed. Maybe "Erase All"? It should of course ask for confirmation. (It does not belong under "Get All".) By "Erase" do you mean the current Erase Customization functionality or something else? I thought that we had more or less agreed to separate the two functionalities that are mixed today in Erase Customization. Yes. See my other, "New tack" message today. Instead of removing things from the custom file to remove customizations and return to standard values, why not just add a declaration to custom-set-variables (at the _end_ of the file) that the standard values should be used.