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: Tue, 15 Feb 2005 09:51:55 -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 1108491664 3927 80.91.229.2 (15 Feb 2005 18:21:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Feb 2005 18:21:04 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 15 19:21:03 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D17J6-00025e-8z for ged-emacs-devel@m.gmane.org; Tue, 15 Feb 2005 19:20:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D17Ys-0005Bn-Vq for ged-emacs-devel@m.gmane.org; Tue, 15 Feb 2005 13:36:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D17TQ-00030q-7z for emacs-devel@gnu.org; Tue, 15 Feb 2005 13:31:00 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D17TK-0002y4-57 for emacs-devel@gnu.org; Tue, 15 Feb 2005 13:30:55 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D17TJ-0002mP-0T for emacs-devel@gnu.org; Tue, 15 Feb 2005 13:30:53 -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 1D16rf-0003Sl-R1; Tue, 15 Feb 2005 12:52:00 -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 j1FHpwbx011678; Tue, 15 Feb 2005 09:51:58 -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 j1FHpvWD011650; Tue, 15 Feb 2005 09:51:57 -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 j1FHpuJL011549; Tue, 15 Feb 2005 10:51:56 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-64-165.vpn.oracle.com [141.144.64.165]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1FHptVS011530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 15 Feb 2005 10:51:56 -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:33494 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33494 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. This is confusing now only because the button doesn't properly indicate that the action is to Save All. As we discussed, renaming the button (All) and asking for confirmation should take care of this. ("This will save all options in the buffer that have been Set. Do you want to continue?"). One possible solution for that is to discourage, or even get rid of, of the per-variable command button. If there is only the whole-buffer Set and the whole-buffer Save, this confusion won't happen. ISTR that I have seen apps where there is no difference between the field value and the active value within the customization tool, but all the changes require confirmation when you exit the customization tool. The concept of "exiting" does not make sense for a Custom buffer, but there could be a buffer-wide Activate command, "Put this in effect", which combines Set and Save. That's just what the Save button does currently, IIUC. If that were the only way to make values take effect, it would be a lot simpler than the current Custom facility. In addition to Activate, there would be Cancel and Standard Values. And perhaps What's Changed, which says what would change if you use Activate right now. What do people think of the idea? I think that it would be a very bad idea to move away from being able to manipulate (e.g. edit, set, reset, & save) individual options. A given custom buffer will perhaps have many options in several different states. There must be a way to save one or more options in the buffer but not necessarily all. Otherwise, we will get more confusion and operator error. We might want to let users select a set of individual options (e.g. using checkboxes or by dragging a region) and then operate on the selection. That would provide a shortcut to operating individually on each item in the set, and could help make it clear which options were affected for a "global" operation. But to always use the entire Customize buffer as that selection would be restrictive, IMO. WRT the idea of checkboxes - I'm thinking of what we do in Dired to mark (select) files for applying actions. You can use many different ways to mark a file (regexp etc.). In my own Dired code, you can also: - Use the mouse to drag a region, then use a mouse-3 menu item Mark (or Unmark) to select (or deselect) all the files in the region. If no region is active (no selection), then the mouse-3 menu items affect the single file under the pointer. - Use SHIFT and CONTROL with mouse-1 clicks to select blocks of files or individual files to add to the selection set - just as you do in Windows Explorer. Extending this idea to Customize, a user would mark/select various options, then use a global action (button or menu-bar menu item) that operates on all of the selected options. If no options are selected, then the menu item would apply to the option under the pointer. The menu for this is the individual-option menu, which is currently accessed by the State "button". This could remain as a pulldown menu (which is what it really is now), or it could be moved to a contextual menu on mouse-3 (as I have in Dired). In the latter case, mouse-3 would not be available for selecting and killing, but users could still select a region by dragging. I assume that this discussion applies to possible changes after the release, not before.