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: Sat, 14 Jun 2008 02:45:47 -0700 Message-ID: <00b601c8ce03$6c7db2e0$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><00b101c8cda2$63175a50$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 1213436796 15381 80.91.229.12 (14 Jun 2008 09:46:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2008 09:46:36 +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 11:47:19 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 1K7SLs-000581-HP for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 11:47:17 +0200 Original-Received: from localhost ([127.0.0.1]:48295 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7SL4-0006H3-4a for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 05:46:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7SKV-0005x2-IN for emacs-devel@gnu.org; Sat, 14 Jun 2008 05:45:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7SKT-0005up-RY for emacs-devel@gnu.org; Sat, 14 Jun 2008 05:45:50 -0400 Original-Received: from [199.232.76.173] (port=37446 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7SKT-0005uc-1c for emacs-devel@gnu.org; Sat, 14 Jun 2008 05:45:49 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:64817) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K7SKS-0000Ix-TN for emacs-devel@gnu.org; Sat, 14 Jun 2008 05:45:49 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m5E9jkdH014453; Sat, 14 Jun 2008 03:45:46 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m5E7G6hk023913; Sat, 14 Jun 2008 03:45:44 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3694271211213436742; Sat, 14 Jun 2008 02:45:42 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 14 Jun 2008 02:45:42 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjN0HIGBEiKnI6kQISPspmulB+DPwAKc7Dg 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:99169 Archived-At: BTW, your changes introduced a bug: emacs -Q load your info.el (from CVS) C-h i choose Emacs manual T Wrong type argument: stringp, toc > > It is the breadcrumbs line where > > space is critical; it is likely to be longer than the > > header-line. > > In my tests (and with my setup), the header-line already tends to > overflow more than the breadcrumbs I said header-line, but I meant the second line (what is it called?). Are you perhaps using a nil value for `Info-use-header-line'? The default value is t (at least on Windows). In the default case, it is the breadcrumbs line that is likely to be longest. Personally, as I said, I _like_ the addition of the top and current nodes to the breadcrumbs, and their removal from the second line (or the first line, if `Info-use-header-line' is nil). (I didn't do that myself because I figured there would be too much resistance to a change that removes them from their traditional spot.) But I also think the breadcrumbs, when used at all, should be complete - never elided. They should also be filled, so that (like the Info body text) they stay within 72 chars without wrapping. I'd suggest therefore getting rid of the depth user option altogether. If you feel you must keep it, then please make its default value 5, which includes everything (the 4 possible section levels plus the top level). By default, at least, no breadcrumb nodes should be elided. > I introduced the depth first and foremost to ensure termination. I saw that, and that in itself is fine. I'm talking about the option. You can still use depth (5) in the code to ensure termination, without having a depth user option. Your code just uses the option to initialize the internal depth counter. > > . When using ellipsis, I suggest dropping first the current > > node name and the file+top - precisely the parts you keep. > > I keep them precisely because they were there before. > The number of nodes actually displayed depends on too many > things: to be really precise, the docstring would need to be overly > complex. The question is what should be dropped when using ellipsis. The current and top nodes are the least important parts to keep in the breadcrumbs, for the reasons I gave. _If_ you drop anything, they should be dropped. However, I really think nothing should ever be dropped (elided) from the breadcrumbs. Instead, they should just be filled at 72 chars (splitting at `>'). > > . 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. > > You misread the code. It's possible. But FWIW I followed it (my version, which stopped only at Top, not via depth) in the debugger, and that binding did save unnecessary work. But that was only manifested in certain nodes (Multiple Displays, IIRC). BTW, I wonder if there isn't a bug in the text of node Multiple Displays. Looking at its raw text, it seems different from its siblings: no explicit Up, Prev, or Next; no underline of the node title. Perhaps this difference is what caused the extra fontification attempts that I saw (related to the fragility of the Top test)?