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: breadcrumbs for Info . . . . . . Date: Fri, 13 Jun 2008 08:12:26 -0700 Message-ID: <004e01c8cd67$e4184320$0200a8c0@us.oracle.com> References: <009d01c8cb55$13d53e20$0200a8c0@us.oracle.com><87fxrkltma.fsf@jurta.org><00ae01c8cb71$c26aeef0$0200a8c0@us.oracle.com><873ankqou6.fsf@jurta.org><00d901c8cbc9$7df36fb0$0200a8c0@us.oracle.com><87tzfzk331.fsf@jurta.org><00a501c8ccdd$93328720$c2b22382@us.oracle.com><002401c8cd1f$98631650$0200a8c0@us.oracle.com><87hcbxd8t8.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1213370037 12148 80.91.229.12 (13 Jun 2008 15:13:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Jun 2008 15:13:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" , "'Thien-Thi Nguyen'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 13 17:14:40 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K7Az9-0001EQ-9h for ged-emacs-devel@m.gmane.org; Fri, 13 Jun 2008 17:14:39 +0200 Original-Received: from localhost ([127.0.0.1]:44613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7AyK-0003BM-QM for ged-emacs-devel@m.gmane.org; Fri, 13 Jun 2008 11:13:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7Axm-0002RZ-L2 for emacs-devel@gnu.org; Fri, 13 Jun 2008 11:13:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7Axk-0002O4-HA for emacs-devel@gnu.org; Fri, 13 Jun 2008 11:13:14 -0400 Original-Received: from [199.232.76.173] (port=37024 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7Axk-0002No-9a for emacs-devel@gnu.org; Fri, 13 Jun 2008 11:13:12 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:41097) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K7Axj-0005wd-J9 for emacs-devel@gnu.org; Fri, 13 Jun 2008 11:13:11 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m5DFD6r6016204; Fri, 13 Jun 2008 10:13:06 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m5CF9cQ2010271; Fri, 13 Jun 2008 09:13:06 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3692304521213369944; Fri, 13 Jun 2008 08:12:24 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2008 08:12:24 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjNXxDyjRIk7h9AQbKLjGg96bosBgABHoCQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:99111 Archived-At: > > Bias note: personally, i dislike features that use screen space. > > If there is another line taken for breadcrumbs, i will find a way > > to remove it. > > Of course, that's always a problem. Emacs being what it is, we'll of > course make it an option. This said, I think it'd be > worthwhile to try and make it all fit onto the existing header-line. I don't think so, except perhaps when it would still keep the header-line less than 70 chars. Info files generally are formatted to be at most 70 (or perhaps 72, it seems) chars wide - and that's a good thing. The combination of (a) header line, (b) the next line (what's it called?) with File and Node, and (c) breadcrumbs could perhaps be optimized _sometimes_ to take up only two lines. However, we wouldn't gain much doing that, and users would lose some predictability wrt where things are located. It's important that the same thing (e.g. File) always be in essentially the same location. In no case should any of these three lines be wider than the 70//72 chars that are used for the buffer text itself. That already occurs for a few nodes now, I believe, which is too bad. Before the existence of a standalone header line, that happened quite often - the header line brought sanity to the header area. It is much better, IMO, to sacrifice another line, when things don't all fit on the same line within 70 columns, than it is to have a superwide line. > One way to make it might be to abbreviate node names. But > I'm not sure how best to do that. Maybe we should try to elide/abbreviate > a (sequence of) word from a node name when that (sequence of) word > already appears in the node's parent. The node name, which appears in the mode line and the Node field, is already abbreviated wrt the node (section) title. That's sufficient, and most of the node names are quite short. There should be a single, canonical node name, used everywhere. Abbreviating node names more than that, especially automatically, is a bad idea. If some node names are currently too long, then they should be shortened, on a case-by-case basis, taking into account the context. Sometimes node names that are too long reflect insufficient document structure, which can be relieved by restructuring. More commonly, names are too long out of laziness. It takes thought to find appropriate shorter names - an automatic abbreviation mechanism will not cut the mustard. Occasionally the fault is (presumably) politics: "GNU Free Documentation License" instead of just "GNU License", "GFDL", or "License".