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: Why doesn't Info `T' cache node tree for current file? Date: Wed, 11 Jun 2008 06:46:39 -0700 Message-ID: <00da01c8cbc9$932a7f40$0200a8c0@us.oracle.com> References: <004001c8cb1b$69006c10$0200a8c0@us.oracle.com> <004201c8cb25$1b2be870$0200a8c0@us.oracle.com> <009501c8cb3c$9246d110$0200a8c0@us.oracle.com><877icwn8l0.fsf@jurta.org><00ad01c8cb71$bb7d1960$0200a8c0@us.oracle.com> <878wxctirr.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 1213192247 5704 80.91.229.12 (11 Jun 2008 13:50:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Jun 2008 13:50:47 +0000 (UTC) Cc: 'Eli Zaretskii' , emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 11 15:51:30 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 1K6QiR-0008DZ-PY for ged-emacs-devel@m.gmane.org; Wed, 11 Jun 2008 15:50:20 +0200 Original-Received: from localhost ([127.0.0.1]:42402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6Qhe-0005yK-B9 for ged-emacs-devel@m.gmane.org; Wed, 11 Jun 2008 09:49:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K6Qgx-0005gS-B6 for emacs-devel@gnu.org; Wed, 11 Jun 2008 09:48:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K6Qgu-0005eK-He for emacs-devel@gnu.org; Wed, 11 Jun 2008 09:48:46 -0400 Original-Received: from [199.232.76.173] (port=44854 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6Qgu-0005eB-Cx for emacs-devel@gnu.org; Wed, 11 Jun 2008 09:48:44 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:14045) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K6Qgn-0003N3-GZ; Wed, 11 Jun 2008 09:48:37 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m5BDmZCq015649; Wed, 11 Jun 2008 07:48:35 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m5B7j9eK029873; Wed, 11 Jun 2008 07:48:35 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3692030031213192000; Wed, 11 Jun 2008 06:46:40 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Jun 2008 06:46:40 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <878wxctirr.fsf@jurta.org> Thread-Index: AcjLqbvBpqwQ8RgeSSWSzbU0fuoQjAAHv0eA 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:98955 Archived-At: > >> It is not very quick, since the code has to reread all > >> Info subfiles (its slowest part). > > > > That was my thinking - it really does seem to do quite a > > lot of work. > > > > On the other hand, at least with the manuals I use (Emacs > > and Elisp), it seems pretty snappy to me. Do you really see > > a performance problem, or is this just hypothetical? > > If you have a fast machine, this doesn't mean everyone has the same. > Try on at least 300MHz proc to see how quick it is. I won't be trying a different machine, but perhaps someone else can. Can you point to a particular manual for which this is unacceptably slow on a slow machine? IOW, can you point to a concrete case that people with slow machines can check? > >> I see one problem: how to refresh the cached TOC buffer when > >> the Info file changes > > > > Do you mean when you go to a different manual (different > > file), or do you mean when someone changes the file on disk? > > > > I think we can ignore the latter (no?). > > The same Info file doesn't change too often, but there are > situations when for instance, the user writes a new Info > manual, and in the process of writing uses the TOC as an > overview of the manual (i.e. iterations like > add a new node, revisit the TOC, reorganize its structure, and so on). Ah, I see - the use case is for Info manual writers. That is important, but it is still a minority use case. Perhaps those people could live with restarting Emacs. Or perhaps they could just delete the cache manually so that it gets rebuilt. IOW, do you really think this is an important enough use case to worry about?