From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Visual cleanup for customize buffers Date: Sat, 14 Jan 2006 13:58:05 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1137275980 17972 80.91.229.2 (14 Jan 2006 21:59:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2006 21:59:40 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 14 22:59:39 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ExtQt-0006s5-7r for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2006 22:59:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExtT5-0003LR-L0 for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2006 17:01:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ExtRt-0002ee-Ql for emacs-devel@gnu.org; Sat, 14 Jan 2006 17:00:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ExtRs-0002dL-90 for emacs-devel@gnu.org; Sat, 14 Jan 2006 17:00:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExtRr-0002d7-R7 for emacs-devel@gnu.org; Sat, 14 Jan 2006 17:00:36 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ExtV5-0007V0-J9 for emacs-devel@gnu.org; Sat, 14 Jan 2006 17:03:55 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0ELwDQN017145 for ; Sat, 14 Jan 2006 15:58:14 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0ELwDkK023084 for ; Sat, 14 Jan 2006 14:58:13 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw6-141-144-112-71.vpn.oracle.com [141.144.112.71]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k0ELwCuK023072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 14 Jan 2006 14:58:13 -0700 Original-To: 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.1506 Importance: Normal In-Reply-To: X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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 Xref: news.gmane.org gmane.emacs.devel:49102 Archived-At: - If we keep global buttons (or equivalent menu items or whatever) that operate on multiple preferences all at once, each button action should: 1) explicitly list the preferences that will be affected or those that will *not* be affected (or perhaps both?), whichever group is smaller, and 2) require confirmation. That could be a good solution to that flaw, if it works out well in practice. - One way to do this would be to provide a check box next to each preference in the buffer and 1) precheck the boxes of those preferences that the program thinks could be targets If the "hide value" buttons control this, we don't need a checkbox to control it too. You're right that we don't need two different mechanisms to control this. But hide/show currently does two things: 1) control the scope of whole-buffer actions and, 2) well, hide/show stuff. Check boxes are only one suggestion for #1. In any case, I think it might make sense to separate show/hide (which has as aim to remove clutter or show details) from selection or marking of preferences for acting upon. I like the way this is done in Dired. There, we have one mechanism for marking files to act upon and another mechanism (kill lines) for hiding ("omitting") files - we don't simply expect people to hide all the files that are not to be acted upon. It's true, however, that if you hide a file in Dired and then try to, say, mark all files that have its extension, the hidden file will not be marked - hidden files are not seen by marking commands. This does mean that you can, in effect, use hide instead of unmark in many cases - but you cannot use show instead of mark: the scope of actions is always indicated explicitly by the presence of visible marks. If Dired were like Customize is currently, then the only mechanism for "marking/unmarking" files would be hiding/showing them. I think that would be a step backward, because it is clearer to see both the marked and the unmarked objects when you perform an action on the former. So, for Customize as for Dired, perhaps it is better not to have the target set for actions be affected by what is currently visible. No matter which way the design works, there can be confusion if the two (mark & show) are related: if actions affect hidden stuff, then you are not seeing everything that is affected; if they don't affect hidden stuff, then you can end up using only show/hide also to determine the scope of actions (giving it two different purposes). To me, show/hide has its own use and purpose, and it should probably not also define the scope of actions. However, as in the case of Dired, it could affect what gets "unmarked" (and so, indirectly, what gets acted upon). The marks would at all times show explicitly what will be acted upon, however. Dired handles marks on hidden stuff pretty well, I think: 1) you cannot mark a hidden file (it is not seen by marking commands), and 2) if you hide a file that is (already) marked, it is unmarked by hiding it. This means that all hidden files are unmarked, but the hide/show mechanism is not generally what is used to directly control the scope of actions - instead, explicit marks indicate that scope. And although hide effectively causes unmark, show never causes mark. Whatever we decide, the scope of actions should somehow be made clear in the case of hidden stuff - let the user know that foo and toto are hidden and therefore won't be acted upon (e.g. saved) - or will be acted upon, depending on the design we choose (I prefer the former). The use of a separate marking mechanism would, as in the case of Dired, help make this clear: it is simple in Dired to check whether marking affects hidden files (no) and whether hiding affects marked files (yes). And most importantly, an explicit mark, not the visibility of objects, indicates the scope of actions.