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: Inconsistency in whole buffer buttons. Date: Fri, 13 Jan 2006 10:16:23 -0800 Message-ID: References: <200601130314.k0D3ECv16479@raven.dms.auburn.edu> 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 1137183727 4422 80.91.229.2 (13 Jan 2006 20:22:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 13 Jan 2006 20:22:07 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 13 21:22:02 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 1ExVQn-0001Le-Nv for ged-emacs-devel@m.gmane.org; Fri, 13 Jan 2006 21:21:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExVSw-00072s-QW for ged-emacs-devel@m.gmane.org; Fri, 13 Jan 2006 15:24:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ExTWI-0003bj-Jj for emacs-devel@gnu.org; Fri, 13 Jan 2006 13:19:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ExTWG-0003aY-33 for emacs-devel@gnu.org; Fri, 13 Jan 2006 13:19:24 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExTWF-0003aD-7a for emacs-devel@gnu.org; Fri, 13 Jan 2006 13:19:23 -0500 Original-Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.34) id 1ExTZG-0002ui-EU for emacs-devel@gnu.org; Fri, 13 Jan 2006 13:22:30 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by mx20.gnu.org with esmtp (Exim 4.34) id 1ExTTt-0007k9-RW for emacs-devel@gnu.org; Fri, 13 Jan 2006 13:16:58 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0DIGXl8002846 for ; Fri, 13 Jan 2006 12:16:33 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0DIGWoH016655 for ; Fri, 13 Jan 2006 11:16:33 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw6-141-144-115-191.vpn.oracle.com [141.144.115.191]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k0DIGV9F016645 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 Jan 2006 11:16:32 -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: <200601130314.k0D3ECv16479@raven.dms.auburn.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal 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:49012 Archived-At: So my idea for after the release would be: Single option buffers: all current State Menu items become whole buffer buttons (some under a heading "Advanced"), no State button. Multiple-option buffer: whole buffer buttons and other whole buffer functionality only available upon setting a defcustomed option, disabled by default. _Maybe_ a State Menu button as now, _maybe_ a "Customize" button (or link) that if you click on it sets up a single option buffer. If the latter, users could replace it with the current State Menu button using another customizable option. In other words, for beginning users, group and other multi-option buffers could be pure browsing tools, actual customization happens in single-option buffers, after clicking the appropriate "Customize" button. I have even heard several advanced users say that they only customize in single option buffers. I myself use the State buttons. I would like us to discuss Customize generally, after the release - especially, but not only, the UI. For now, I'd like to thank Luc for 1) looking so closely at the workings of customize (I'm glad someone understands how it works!) and 2) making good suggestions and changes to Customize for the current release. I think we'd lose a lot without his careful attention to detail. Customize is a bear to use and a bear to get right (design & implementation). I hope we do make the effort to revisit customize after the release, though that might call into question some of the changes made now. Anyway, what Luc has proposed for this release sounds good to me. Regarding Luc's proposals for changes after the release (sorry for the length) - Wrt single-option customize buffers: - Is the only difference that between a menu and separate buttons? If so, this is without great consequence. Buttons are better for this, provided there are not too many of them. However, the same actions should also be available in 1) a menu-bar menu and, perhaps, 2) a mouse-3 popup menu. I think Luc's point is that the raison d'etre for the State menu is to provide a local choice for a single preference within a buffer of multiple preferences - so, such a menu isn't needed in a single-preference buffer. Wrt the proposed options for dealing with multi-preference customize buffers, we should discuss this more after the release, but, for now: - What's convenient for advanced users is also convenient for novices: 1) If it is convenient to _see_ multiple preferences (e.g. faces) together when you operate on one (e.g. State menu), then this is even more important for non-experts. 2) If it is convenient to _operate_ on multiple preferences all at once (e.g. global button), then this is just as important for non-experts. We should either keep global buttons or get rid of them - for everyone. - 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. We might need to finagle this so it isn't too clumsy, but we need to somehow explicitly let the user know that foo will *not* be affected and toto and titi will be affected. See alternative suggestion, below. - I'd prefer letting (that is, making) the user explicitly choose the preferences to act on. It is convenient to be able to act on several at once (vs repeating the action on each separately). But, for example, a user might want to save several, but not all, of the preferences s?he has changed. That is, the set of targets to act on should be decided by the user, not by program. The program can guess what the user might want to act on, but the user should at least confirm that selection and, preferably, should be able to modify the selection. - 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 (e.g. all changed preferences could be targets for saving), but 2) let the user change the target set by checking/unchecking individual boxes. #2 is analogous to a user marking multiple files in Dired for performing some action. (#1 has no analogy in Dired.) - We might also make it possible for a user to check/uncheck multiple boxes at once, by selecting those preferences (drag a region) and using a popup menu item Mark Selected (or Unmark Selected). I do that, for instance in an enhancement to Dired, and something similar is commonly used in Windows Explorer (not Internet Explorer, but the Windows imitation of Dired plus speedbar). - If we disallowed making multiple changes together, and instead, as suggested by Luc, let users open a separate customization buffer by clicking a "Customize" button (there's a problem of overloading "customize", here, BTW), we should open that buffer in a separate window, so users can continue to see the other, related preferences. This is mainly important for faces: It's helpful to be able to see the result of customization (the new face appearance) at the same time as the appearance of other, related faces. I have other thoughts on improving customize after the release, as I'm sure others do also. One thing I would really like to see affects any buffer that uses widgets, not just customize buffers: Be able to do `C-h k' (or equivalent) on a widget, to see what Lisp function it ultimately applies. You can do this with a menu item, but not with a widget (button, etc.). That drives me crazy when I try to figure out what the customize code is actually doing, and how it does so. What we have, IIUC, is partial OOP, and it doesn't seem to fit too well with the rest of Emacs (in the sense just given). I have a similar problem with menu items that are generated dynamically. Here's what you see, for instance, if you do `C-h k' and pick File > Print > PostScript Print > Buffer > 1-up: <1-up> runs the command menu-function-33 which is an interactive Lisp function. It is bound to <1-up>. (menu-function-33) Not documented. Besides being redundant (key foo runs command bar, which is bound to key foo), this tells you less than you started with! It takes you from a partly meaningful description of the key (the menu item itself: 1-up PostScript printing of a buffer) to something completely opaque: `menu-function-33' (for which there is no further info). Thanks, but no thanks. Emacs is great, in part, because you can drill down from the UI to the source code transparently. The opacity imposed by such dynamically created menus and by widgets is an obstacle to understanding. I would love to see such obstacles removed, though my guess is that that wouldn't be trivial to accomplish. Thanks again to Luc (and others) for chipping away at the customize code.