From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: karl@freefriends.org (Karl Berry) Newsgroups: gmane.emacs.devel Subject: Re: Documentation for "Clone Buffers" (corrected version) Date: Thu, 18 Mar 2004 13:37:30 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200403181837.i2IIbUV23148@f7.net> References: <87brmxjmp9.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1079635459 2463 80.91.224.253 (18 Mar 2004 18:44:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 Mar 2004 18:44:19 +0000 (UTC) Cc: eliz@elta.co.il, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Mar 18 19:44:09 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B42Uz-0006jj-00 for ; Thu, 18 Mar 2004 19:44:09 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B42Uz-0008RS-00 for ; Thu, 18 Mar 2004 19:44:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B42TN-0004My-CT for emacs-devel@quimby.gnus.org; Thu, 18 Mar 2004 13:42:29 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B42Sg-0004Lg-Do for emacs-devel@gnu.org; Thu, 18 Mar 2004 13:41:46 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B42RJ-00041f-Cy for emacs-devel@gnu.org; Thu, 18 Mar 2004 13:40:52 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1B42Q7-0003pd-K2 for emacs-devel@gnu.org; Thu, 18 Mar 2004 13:39:07 -0500 Original-Received: from [209.61.216.22] (helo=f7.net) by mx20.gnu.org with esmtp (Exim 4.30) id 1B42Ob-0004hE-7G for emacs-devel@gnu.org; Thu, 18 Mar 2004 13:37:33 -0500 Original-Received: (from karl@localhost) by f7.net (8.11.7-20030920/8.11.7) id i2IIbUV23148; Thu, 18 Mar 2004 13:37:30 -0500 Original-To: juri@jurta.org In-Reply-To: <87brmxjmp9.fsf@mail.jurta.org> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20587 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20587 which places into dir buffer its own huge index with 1700 entries! The underlying issue, to my knowledge, is that for info to be as convenient as man, it needs to have dir entries for every command, every function, etc. (This is different than every index entry, although of course the bulk of the index consists of such names.) This has been an unresolved issue with the info system since day 1. Having a single dir buffer with every possible name is infeasible, as you say. It's obviously not useful for the user to have to browse through a dir node with 1700 entries from glibc. On the other hand, I can't exactly call it a "bug" in the glibc manual, it's trying to do the only thing available. (I assume it's not literally putting every index entry into dir, just the function etc. names -- that was true last time I looked at it.) The only long-term solution I've been able to think of is to allow subnodes of (dir) and have the info readers look through the subnodes when asked for a given top-level name -- but not load or display the info in all the subnodes when showing the dir node itself. If anyone has any other bright ideas, just speak up ... thanks, k