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: alternative Customize displays: 1) flattened group, 2) expandable tree, 3) explorer: tree+flattened, 4) mouse-3 menu Date: Fri, 22 Dec 2006 12:08:17 -0800 Message-ID: NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1166818230 20545 80.91.229.10 (22 Dec 2006 20:10:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 22 Dec 2006 20:10:30 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 22 21:10:28 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1Gxqif-00009f-MT for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2006 21:10:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gxqif-00013r-5U for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2006 15:10:17 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gxqhk-0000Qx-GR for emacs-devel@gnu.org; Fri, 22 Dec 2006 15:09:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gxqhi-0000Op-Ub for emacs-devel@gnu.org; Fri, 22 Dec 2006 15:09:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gxqhi-0000OX-HB for emacs-devel@gnu.org; Fri, 22 Dec 2006 15:09:18 -0500 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gxqhh-0004WM-Dc for emacs-devel@gnu.org; Fri, 22 Dec 2006 15:09:18 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id kBMK956r015450 for ; Fri, 22 Dec 2006 13:09:05 -0700 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id kBMGoO4m022164 for ; Fri, 22 Dec 2006 13:09:04 -0700 Original-Received: from dhcp-amer-csvpn-gw2-141-144-73-248.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 2314801331166818099; Fri, 22 Dec 2006 13:08:19 -0700 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= 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:64125 Archived-At: For consideration after the release: 1. Customize groups can have subgroups. The guideline is to use no more than 12 options + faces per group. This encourages the use of group hierarchies that are not too shallow, which is a good thing. (AFAIK, there is no guideline for the number of subgroups per group, however.) However, sometimes the inclusion of an option or face in a particular subgroup is somewhat arbitrary. In any case, even when it is not, it is not always obvious to a Customize user which (sub)group to examine to find a particular option (whose name might not be recalled, so `customize-group' would still be an appropriate access method). Suggested alternative Customize display: Let users see all of the options and faces that are in a group, including those that are in its subgroups (and so on, recursively). That is, provide a Customize buffer that shows a group with its subgroups flattened (recursively), in a single alphabetical list. Searching the list for a group would then be an alternative to looking directly in the right subgroup. In sum, a flat listing as a user alternative to the current hierarchical view. The flattened list would show only the option and face names - no descriptive text, buttons, or customization fields. Descriptions would be available via tooltips, not buffer text. The option and face names would be links to their individual Customize buffers. Because the description and customization fields and buttons would be removed, and the names themselves would be links, the display would be clean and compact. (If people think it's important to provide the customize stuff locally, in the group listing, then, instead of opening a separate Customize buffer for the option or face, the name link could expand to show the stuff locally. That would not be my preference, however.) 2. As another alternative to the current Customize display, how about providing a real tree view, with just the group names (the group descriptions would be provided via tooltips, not buffer text). This would be like other tree displays in Emacs (e.g. speedbar), with expandable (+) and contractable (-) nodes. contracted: (+) Emacs expanded: (-) Emacs (+) Editing (+) External (+) Convenience (+) Programming (+) Applications ... [BTW, the subgroups should be listed alphabetically, but they are not, currently.] These alternative Customize displays (#1 and #2) could be provided via new buttons or menu items, as well as by new commands (or by prefix args to `customize-group'). 3. Suggestions #1 and #2 could be combined: Each group name in the +/- tree view would be a link (reducing the extra "group: Go to Group" verbiage that is used now). If you clicked a group name, e.g. Emacs or Editing, the right half of the frame would show, in another window, a (flattened, alphabetical) list of all of the options and faces in that group, perhaps with the group description (one-liner) at the top of that buffer. So, if you clicked Emacs, you would see a list of all options and faces in group Emacs; if you clicked Editing, you would see a list of all that are in subgroup Editing (and its subgroups), and so on. The display of the contents of a group, at the right, would be independent of the expansion and contraction of tree nodes, at the left, except that the group whose contents are currently displayed at the right would be highlighted in the tree view, at the left. This would be similar to what Windows Explorer does for directories and files, except that instead of showing the subgroup names in a group listing (at the right), the group listing would be complete (flattened). This would give you easy navigating, as well as alphabetical lists at any level of granularity. The display would be much less noisy (busy) than it is now: noise would be manifested only upon demand ;-). 4. In addition to providing descriptions via tooltips, we could have a right-click (i.e. mouse-3) menu with a Properties item that provides the description and perhaps other information. This too is MS Windows-like, but it is quite handy, IMO. This right-click binding would be in effect only when the mouse is over a group, option, or face name link. Additional menu items that pertain to the clicked object could be provided - e.g. the `custom-group*' stuff for a group, the `custom-face*' stuff for a face...