From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Documentation for "Clone Buffers" (corrected version) Date: Mon, 22 Mar 2004 00:25:15 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200403211718.i2LHIpY06619@f7.net> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1079933961 19637 80.91.224.253 (22 Mar 2004 05:39:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 22 Mar 2004 05:39:21 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Mar 22 06:39:17 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 1B5I9d-00020t-00 for ; Mon, 22 Mar 2004 06:39:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B5I9c-0002at-00 for ; Mon, 22 Mar 2004 06:39:16 +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 1B5I9J-00065J-JP for emacs-devel@quimby.gnus.org; Mon, 22 Mar 2004 00:38:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B5I0y-00010o-Iy for emacs-devel@gnu.org; Mon, 22 Mar 2004 00:30:20 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B5I0N-0000iH-9n for emacs-devel@gnu.org; Mon, 22 Mar 2004 00:30:14 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B5I0M-0000hK-9W for emacs-devel@gnu.org; Mon, 22 Mar 2004 00:29:42 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.24) id 1B5Hw3-0007Ae-4a; Mon, 22 Mar 2004 00:25:15 -0500 Original-To: karl@freefriends.org (Karl Berry) In-reply-to: <200403211718.i2LHIpY06619@f7.net> (karl@freefriends.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:20708 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20708 In your proposal of messing with Top node menus, I don't see that @dircategory matters at all. The Info readers read the top-level dir file, get the list of Info manuals to look in, then go look at each of their Top menus to virtually construct the list of whatever the user is interested in. Do I have the general idea right? Partly. It would not read all of the dir file, just a subnode. It would not make the list based on the entire Top node menus as a whole; rather, it would obey certain special entries in them. The point of using @dircategory is to put entries for certain manuals into the subnode of dir. Along that line, what comes to my mind is a second optional argument to @dircategory, specifying the subnode of dir to use (Shell Commands, C Functions, or whatever). I don't understand why this optional argument is necessary. Can't @dircategory already do this job with no change, if we set up the dir file properly? If you think this won't work, could you explain the precise problem? install-info could then insert the given entries into a subnode of dir named "Shell Commands", in a category "GNU Emacs'. I don't see a need for categories within the menu in the Shell Commands node. That node would exist specifically for man-style lookup. The order of manuals within that node would not matter. So it only needs to have one category, which could be called Shell Commands. All the manual needs is @dircategory Shell Commands This way, no changes are needed in the specifications of the Texinfo language. People could change manuals starting immediately, without waiting to be able to install a new version of Texinfo. Then, people can say info 'Shell Commands' emacsclient They could, but that's awfully clumsy. We would want to change info so that something simpler can be used, such as info command emacsclient Users won't get the benefit of that improvement until they install a new version of Texinfo. Perhaps that is unavoidable, but at least it doesn't lengthen the critical path. Which brings up the point that it would be *ideal* if manual writers create separate @direntries for each function name, so that descriptions are available for searching: @dircategory libc, C @direntry * strcmp:(libc)Whatever. Compare two strings. @end direntry That is what I am trying to avoid! There is no reason to clutter up the dir file by copying large amounts of text from a few manuals. It is much better for info readers to search those few other manuals when the time comes. The only case where it is worth copying the information into the dir file is when it comes from many different manuals.