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 custom fileshouldaskforconfirmation Date: Thu, 3 Feb 2005 11:30:34 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1107459713 16045 80.91.229.2 (3 Feb 2005 19:41:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Feb 2005 19:41:53 +0000 (UTC) Cc: rms@gnu.org, abraham@dina.kvl.dk, Lennart Borgman , emacs-devel@gnu.org, Stefan Monnier , miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 03 20:41:52 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cwmpb-0007QC-36 for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2005 20:39:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cwn2y-0004rp-3F for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2005 14:53:48 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cwn2h-0004o4-4X for emacs-devel@gnu.org; Thu, 03 Feb 2005 14:53:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cwn2c-0004m6-Oh for emacs-devel@gnu.org; Thu, 03 Feb 2005 14:53:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cwn2c-0004jx-E6 for emacs-devel@gnu.org; Thu, 03 Feb 2005 14:53:26 -0500 Original-Received: from [141.146.126.230] (helo=agminet03.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CwmhE-0006Dr-Ue; Thu, 03 Feb 2005 14:31:21 -0500 Original-Received: from agminet03.oracle.com (localhost [127.0.0.1]) by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j13JUcpm024431; Thu, 3 Feb 2005 11:30:38 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j13JUbgc024355; Thu, 3 Feb 2005 11:30:37 -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 j13JUanp008282; Thu, 3 Feb 2005 12:30:36 -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 j13JUYRI008262 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 3 Feb 2005 12:30:35 -0700 Original-To: "Kim F. Storm" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: 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:32834 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32834 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 ... Clear analysis and presentation. 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. Yes, but it is not unfamiliar to most _Emacs_ users. And if it is unfamiliar to newbies, then we have to help them to understand. Emacs is more about dynamic, current values than it is about saved settings, and yes, that is different from what newbies might be used to. This idea should be at the forefront of our Customize UI model. Customizing Emacs is a real-time thing; saving changes is just an option. It's essential that we make clear this difference between customizing in Emacs and in other applications. IMO, we should consider the difference between F and C states as an expert option. I disagree. I do not think we want to change the model or make the C operations for expert-mode only - it would be very confusing to do so. "Set" is the _first_ thing, not the last thing, that we want novices to try; it should definitely not be disabled by default. Learning to use and customize Emacs implies, first and foremost, learning about changing dynamic values. We just need to make the UI clear, so that users realize what each action does. Sure, you can save changed values once you get what you want, but what makes Emacs different is the ease with which you can modify things on the fly and see if that is what you like. Customize is only one way to do that, but it is no exception - it lets you change current values without saving them. Novices more than anyone else need to know that they can make all the changes they want, play with them, and exit with no lasting consequences. They already know there is (there must be) a way to save changes; what they might not know is that they don't _need_ to save a change in order to have it take effect. This "sand-box" mode is the norm for Emacs. IOW, since the Emacs model is different, we need to make that difference clear from the outset, not hide it behind a presentation that pretends at first sight to be the same old change=save model. A user must not need to progress to "expert" status to be able to change things with no permanent consequences. Sand boxes are for novices more than anyone else. 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. 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. I think that using "All" in the names would be good and sufficient. Whenever a user saves values, however, we should of course ask for confirmation. Also the user should be offered to save unsaved customizations when he exits emacs. Agreed. We've discussed this before - perhaps we can do that after the release. I have a prototype that does this (as an option); if you want to see what this might be like, you can try it at http://www.emacswiki.org/elisp/cus-edit-plus.el (Food for thought only - I'm not proposing the code for inclusion in 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). Not a bad idea. But if we do that, the question posed should give the user the option of resetting to a) the current value, b) the saved value, or c) the standard value. That is, we could have a single Reset button with a menu - in fact, I think we already have essentially this behavior, as an option: the Reset menu (`custom-reset-menu'). I suggest the following button names: Since each of these operates on everything in the buffer, they should each use the word "All" (Set All, Save All, Cancel All, Clear All) - or else we should find some other way to make that very clear. In any case, "Clear All" should not be different from the others in this respect. 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. Is there any question that these are the operations we want? I think they are. F => C (Set) F => C,S (set-and-save, which should be called Save) C => S (Save) C => F (Reset from Current) S => C,F (Reset from Saved) D => C,F or D => F (Reset from Standard) To the right are the names I prefer. We could combine the last three into a single Reset button, as mentioned above. However, it might be confusing to combine resetting edit fields with resetting current values. Since we have a Set button, why not confine the reset buttons to resetting only the edit field (F)? That is: 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. - Drew