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: Tue, 10 Jun 2008 20:18:02 -0700 Message-ID: <00ae01c8cb71$c26aeef0$0200a8c0@us.oracle.com> References: <009d01c8cb55$13d53e20$0200a8c0@us.oracle.com> <87fxrkltma.fsf@jurta.org> 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 1213154416 22902 80.91.229.12 (11 Jun 2008 03:20:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Jun 2008 03:20:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 11 05:20:59 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 1K6GtO-0002mY-VH for ged-emacs-devel@m.gmane.org; Wed, 11 Jun 2008 05:20:59 +0200 Original-Received: from localhost ([127.0.0.1]:53668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6Gsb-0002ds-Dw for ged-emacs-devel@m.gmane.org; Tue, 10 Jun 2008 23:20:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K6Gs5-00023e-TG for emacs-devel@gnu.org; Tue, 10 Jun 2008 23:19:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K6Gs4-000228-3J for emacs-devel@gnu.org; Tue, 10 Jun 2008 23:19:37 -0400 Original-Received: from [199.232.76.173] (port=37147 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6Gs3-00021y-S5 for emacs-devel@gnu.org; Tue, 10 Jun 2008 23:19:35 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:51877) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K6Gs3-00061l-Qf for emacs-devel@gnu.org; Tue, 10 Jun 2008 23:19:36 -0400 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 m5B3JWAZ009037; Tue, 10 Jun 2008 21:19:32 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m5ALAFU1018610; Tue, 10 Jun 2008 21:19:32 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3690173811213154284; Tue, 10 Jun 2008 20:18:04 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Jun 2008 20:18:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87fxrkltma.fsf@jurta.org> Thread-Index: AcjLWLx+AjZs0QAxQCiq0sA5Cm3KpQAFYCfQ 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:98916 Archived-At: > This is a nice feature, but I think its implementation is too heavy: > to display just one node it has to visit several other nodes. > It would be more optimal to build a tree of all Info nodes after > visiting the first node and to use this cached structure during > displaying an Info node. Now you know why I sent the mail about `T' and TOC. ;-) That was the first approach I thought of: use something similar to the node tree built for `T'. However, I don't think that the current breadcrumbs approach is a problem or that the other (TOC) approach would be better. Why? Because most manuals are not deep. I picked the deepest node I found in the Emacs manual (by looking at the TOC) as the example I sent. And I see no performance problem with that depth. We have only a certain number of possible heading levels, and it works fine for those, AFAICT. Remember, breadcrumbs reflect document structure, not chronological visits (as they always should). They are not meant to duplicate the Back button (`l'). Do you actually see a performance problem (recipe)? On the other hand, the implementation naively visits each ancestor node, using `Info-goto-node'. Very naive. There is no need to do everything that `Info-goto-node' does, just to pick up the Up node names! That could be optimized. I don't feel like working on that, myself, but if someone wants to, go for it. The current approach is very simple - and AFAICT it is fast enough. If you find that it is not, there should be plenty of room for optimization in the current approach. If that would still not be fast enough, then we could look at using a node tree approach. However, should we then automatically precompute the node tree for the whole manual (or perhaps whole subfile), or just build pieces of it as needed (e.g. via breadcrumbs for visited subfiles)? Wrt the other thread (`T' and TOC), unless there is some other reason (e.g. breadcrumbs, other things...), there is no need to prebuild the TOC. Better to wait until the user hits `T'. Of course, once it's built, it could be used for other things.