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: describe-bindings: ^L, bad order, naming Date: Sat, 12 Nov 2005 15:09:57 -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 1131837063 24651 80.91.229.2 (12 Nov 2005 23:11:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 Nov 2005 23:11:03 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 13 00:11:01 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Eb4Vk-00077m-5q for ged-emacs-devel@m.gmane.org; Sun, 13 Nov 2005 00:10:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eb4Vj-0000o3-Gu for ged-emacs-devel@m.gmane.org; Sat, 12 Nov 2005 18:10:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Eb4VZ-0000nf-Tb for emacs-devel@gnu.org; Sat, 12 Nov 2005 18:10:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Eb4VZ-0000nQ-2T for emacs-devel@gnu.org; Sat, 12 Nov 2005 18:10:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eb4VY-0000nM-TS for emacs-devel@gnu.org; Sat, 12 Nov 2005 18:10:05 -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 1Eb4VY-00084q-OF for emacs-devel@gnu.org; Sat, 12 Nov 2005 18:10:04 -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 jACNLqat001300 for ; Sat, 12 Nov 2005 17:21:52 -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 jACNA2vO022053 for ; Sat, 12 Nov 2005 16:10:02 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-73-250.vpn.oracle.com [141.144.73.250]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jACNA19h022037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 12 Nov 2005 16:10:02 -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.1506 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:45853 Archived-At: > Why not just do what the OP suggested: list the section titles in > the beginning, linked to the sections themselves (exactly as in > the *Help* buffer). That would be perfect. Such an approach is > common both on the Web and in technical documents (e.g. > reference-book chapters): a preliminary TOC with links. Though in practice, it's highly annoying in for instance describe-mode, because the "table of contents" is usually very bloated and pushes useful text off the screen. I don't see that, but it could happen if there are many minor modes in effect. IIUC, we would have the same problem using Outline mode for `describe-mode'. If the outline were all closed up, by default, then it would appear just like the TOC. If it were only partly closed up, then the problem you mention would be worse. And worse would happen when any of the outline lines were opened - even more stuff would be pushed off the screen. The only way around the problem you raise, if it really is a problem, is to have a hierarchical outline (or a hierachy of TOCs), which shows a smaller number of more-major topic lines. I don't see the `describe-bindings' content being organized that way - it's naturally flat. I also don't see it having the problem you raise, however. Here's a `describe-bindings' TOC for Dired mode (some other modes would have even fewer entries). Each line would be a link to its list of bindings, and *only* its bindings. IOW, instead of having pages in linear order (^L...^L...^L...), we would have a hyperlinked (shallow) tree. Key Translations Minor Mode Bindings Major Mode Bindings Global Bindings Function Key Map Translations (I'm not sure that's the best order, BTW, but that's the order we have today. And is that "function-key map translations" or "function keymap translations" - or perhaps just "function-key translations"?) That's not too much for one screen, is it? The link could open the appropriate bindings list in another window (another frame, if pop-up-frames = non-nil), so that the TOC remains visible. If not, the bindings-list pages should at least have a Back button, to get back to the TOC. Yes, that's just like outline mode, but the link metaphor is more obvious and more familiar. Yes, if we had +/- signs, outline mode would act like the GUI trees that people are accustomed to, and it would be (almost) as good as the TOC, here.