From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Documentation for "Clone Buffers" (corrected version) Date: 19 Mar 2004 12:31:07 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200403181837.i2IIbUV23148@f7.net> <1438-Fri19Mar2004165933+0200-eliz@elta.co.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079717745 23537 80.91.224.253 (19 Mar 2004 17:35:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 19 Mar 2004 17:35:45 +0000 (UTC) Cc: juri@jurta.org, emacs-devel@gnu.org, karl@freefriends.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Mar 19 18:35:35 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 1B4NuB-0003tJ-00 for ; Fri, 19 Mar 2004 18:35:35 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B4NuB-0003Zd-00 for ; Fri, 19 Mar 2004 18:35:35 +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 1B4NsB-0000v1-Vj for emacs-devel@quimby.gnus.org; Fri, 19 Mar 2004 12:33:31 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B4NqX-0000T8-Lc for emacs-devel@gnu.org; Fri, 19 Mar 2004 12:31:49 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B4Npz-0000KV-GF for emacs-devel@gnu.org; Fri, 19 Mar 2004 12:31:47 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4Npy-0000K0-V4 for emacs-devel@gnu.org; Fri, 19 Mar 2004 12:31:15 -0500 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id CBD83204D3; Fri, 19 Mar 2004 12:31:07 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id B4FF08B4C3; Fri, 19 Mar 2004 12:31:07 -0500 (EST) Original-To: Eli Zaretskii In-Reply-To: <1438-Fri19Mar2004165933+0200-eliz@elta.co.il> Original-Lines: 60 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-0.001, requis 5, BAYES_44 -0.00) 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:20619 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20619 >> IIRC, Emacs's Info reader already allows the `dir' file to contain several >> nodes, just like any other Info package. > That would not solve the problem at hand, since the reader looks for > the command-line argument in the DIR _node_, not in DIR the file. Indeed, I was just pointing out that part of the requirement is already met and we'd "only" need to extend the search to look at all the nodes in the file. >> Another alternative is to have Info do an index search on some of the >> entries if nothing was found in the `dir' file. > We could try that, but I'm not sure it will do what users want to be > done. Index entries normally include many items that have no relation > to function names; about the only exception to this rule is a library > reference, and even then it's only true for the function index (what > about concept and other indices?). Well, it could lookup the main menu of those packages instead of their index, if that's what you prefer. MY main point is that instead of copying all those entries into the `dir' file it would be better to have a way to say "and look at these other nodes as well", so you can update a libc manual without going through the pain of figuring out which entries are obsolete (another problem with the way the `dir' file is built right now). BTW, my experience with my own `info' script is that using indices rather than main menus works fairly well (i.e. the extraneous entries are not bothersome). But it's admittedly a very small experience and it was a few years ago. >> BTW, why does `info FOO BAR' only look for BAR in the menu of FOO instead >> of (or additionally to) looking for it in the Index? > The actual feature is more general. If you say > info PACKAGE FOO BAR BAZ Sure, but if menu entry BAR does not exist in FOO it may still make sense to look for it in the index. > In other words, if you know the menu path to the node, you can get to it > like that without knowing the node names. For a typical libc, "info libc > index strcpy" will show the section taht describes strcpy (as will > probably "info -n strcpy", but for the latter you need to be sure the node > is called "strcpy", not something like "string functions"). But using the index, you'd just say `info libc strcpy'. And if you tell info to include libc's index by default, you can just say `info strcpy' (without cluttering the dir file). My model here is `man' where `man FOO' tries to guess in which section the thing is placed and `man FOO BAR' looks for BAR in section FOO. `man' is not perfect, but I find this aspect of man's interface to work about as well as I can hope: short and precise. The only problem I've had with it is in the `man FOO' short form because it looks in all chapters, but nowadays you can choose the search order of the various chapters. Stefan