From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Customize buttons that change user's custom fileshouldaskforconfirmation Date: Thu, 03 Feb 2005 10:36:20 +0100 Message-ID: References: <00e301c509c1$9c761690$0200a8c0@sedrcw11488> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1107424010 11696 80.91.229.2 (3 Feb 2005 09:46:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Feb 2005 09:46:50 +0000 (UTC) Cc: rms@gnu.org, abraham@dina.kvl.dk, Lennart Borgman , emacs-devel@gnu.org, Stefan Monnier , Drew Adams , miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 03 10:46:49 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CwdZK-0008Rh-TU for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2005 10:46:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cwdmd-0001R8-74 for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2005 05:00:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CwdlP-0001Ec-Mt for emacs-devel@gnu.org; Thu, 03 Feb 2005 04:59:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CwdlK-0001Bw-Og for emacs-devel@gnu.org; Thu, 03 Feb 2005 04:59:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwdlK-0001Av-BL for emacs-devel@gnu.org; Thu, 03 Feb 2005 04:58:58 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1CwdVu-0007oo-SS for emacs-devel@gnu.org; Thu, 03 Feb 2005 04:43:03 -0500 Original-Received: (qmail 46399 invoked from network); 3 Feb 2005 09:36:20 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 3 Feb 2005 09:36:20 -0000 Original-To: snogglethorpe@gmail.com In-Reply-To: (Miles Bader's message of "Thu, 3 Feb 2005 16:39:04 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) 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:32799 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32799 Miles Bader writes: > Your table helps, but I think it's important to use the proposed > operations, not what the current code does. Here's my version: > > Set: Field => Current > Save: Field => Current, Saved > > Get Current: Current => Field > Get Saved: Saved => Field > Get Default: Standard => Field > > I think these names (and behaviors) make a _lot_ of sense; the > consistency is very appealing, and should help people learn the > meanings easily. The major problem IMHO with Customize is not the names for the operations as such, but the way it differs from other applications that the user may be accustomed to. Customize operates with four values for each variable: F * the field value C * the current value S * the saved value D * the default value It provides commands for the following operations: F => C F => C,S C => S C => F S => C,F D => C,F or D => F In contrast, most other applications only have these states: F * the field value A * the active (current/saved) value D * the default value and consequently has fewer operations: F => A (Save, OK) A => F (Cancel) D => A,F (Clear All) -> with confirmation Consequently, I think the ability to set an option without saving it is unfamiliar to most users -- when you set something and apply the change, they will expect it to be like that from now on. IMO, we should consider the difference between F and C states as an expert option. The big problem is that if the user sets option X on a page and does "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. Also the user should be offered to save unsaved customizations when he exits emacs. Another idea is to combine "C => F" and "S => C,F" states into a single option. We can do this by letting check if C != S and ask the user: Restore to last saved value (y/n) in that case -- otherwise it just restores to C (== S). To summarise: ============= I suggest the following button names: The button does "F => C" when enabled/confirmed. This is an expert command, so it shall be disabled by default (e.g. like narrow-to-region), causing Emacs to ask the novice user if he really wants to do this. The button does "F => C,S" and thus "C => S" when F == C. The button does either "C => F" or "S => C,F". Unless the user has previously used for any of the variables on the page (so C != S), the effect is the same. If C != S, it asks the user: Restore to last saved value (y/n) and acts accordingly. 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. -- Kim F. Storm http://www.cua.dk