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 15:11:10 -0700 Message-ID: <00b101c8cda2$63175a50$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><004a01c8cd67$b2f7a9c0$0200a8c0@us.oracle.com> 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 1213395133 30240 80.91.229.12 (13 Jun 2008 22:12:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Jun 2008 22:12:13 +0000 (UTC) Cc: 'Juri Linkov' , emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 14 00:12:56 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 1K7HVl-0003XG-Os for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 00:12:46 +0200 Original-Received: from localhost ([127.0.0.1]:40070 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7HUx-0003ux-Qp for ged-emacs-devel@m.gmane.org; Fri, 13 Jun 2008 18:11:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7HUs-0003tj-F8 for emacs-devel@gnu.org; Fri, 13 Jun 2008 18:11:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7HUr-0003sr-Ss for emacs-devel@gnu.org; Fri, 13 Jun 2008 18:11:50 -0400 Original-Received: from [199.232.76.173] (port=58646 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7HUr-0003sa-OZ for emacs-devel@gnu.org; Fri, 13 Jun 2008 18:11:49 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:30068) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K7HUr-0004RS-Ec for emacs-devel@gnu.org; Fri, 13 Jun 2008 18:11:49 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m5DMBkwZ029705; Fri, 13 Jun 2008 17:11:46 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m5D5SUfg015297; Fri, 13 Jun 2008 16:11:46 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3693418361213395066; Fri, 13 Jun 2008 15:11:06 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Jun 2008 15:11:06 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjNlWndKv2fNShqSnqw25OOlgsvQwAAeXGg 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:99152 Archived-At: > > Attached. > > I installed a reworked version of this. Thanks. However, what you installed is quite different (and there was no discussion of the differences). Anyway, here is some feedback: . I generally like the replacement of File: and Node: by including that info in the breadcrumbs - bonne initiative. On the other hand (some food for thought): - The current node could be omitted from the crumbs, to save space, since it is already present in (a) the mode-line and (b) the node title. - If the file+top link is moved back to the header-line, more space is saved. In that case, it should be made into a (top) link. (I thought it already was a link, but I see now that that is in my own code). It is the breadcrumbs line where space is critical; it is likely to be longer than the header-line. The file is also listed in the mode-line. - Moving current and file+top to the header-line would probably eliminate any need for the depth option (except to turn off). . When using ellipsis, I suggest dropping first the current node name and the file+top - precisely the parts you keep. This information is redundant (mode-line, title), and there is no action (link) associated with the current node. We have commands to go one level up (`u') and to the top (`t'). It is the intermediate levels that are most important to show - to (a) indicate hierarchical position and (b) provide links. . The `>' appears even at the beginning: "> (dir)Top". That is unconventional and unclear to users, besides wasting a little space. Please remove the initial `>', to clearly indicate that the top node is the starting point of the chain. On the other hand, if you remove the top node to the header-line, then an initial `>' probably helps (for the same reason). . The doc string of `Info-breadcrumbs-depth' should explain that it refers to the number of ancestor nodes, i.e., that it does not include the current node (so it is not the length of the breadcrumbs chain). It should also indicate which nodes are not displayed if too deep, and it should say that they are replaced by ellipsis. . However, the depth value is in fact inconsistent. 1 means show one breadcrumbs of length 2 (including current), but 0 means show breadcrumbs of length zero (i.e., don't show, but use File: and Node: instead). If the inconsistency is retained, then the doc string needs to explain it. It would be simplest to include the current node in the depth (assuming it will be part of the crumbs). In that case, either treat a value of 1 the same as 0, and mention that, or let 1 show just the current node. . You might want to bind `Info-fontify-maximum-menu-size' to nil, as I did, for the calls to `Info-goto-node'. That will save useless extra fontification. . So much for the time I spent shortening lines. You reverted to the original lengths, which includes lines up to 137 chars wide. No problem, but please don't bother to ask for that again.