From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Info enhancements Date: Fri, 12 Dec 2003 23:38:56 +0200 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <874qw5k973.fsf@mail.jurta.org> References: <87ekvahjnr.fsf@mail.jurta.org> <200312121424.hBCEO6V06218@f7.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071267234 17447 80.91.224.253 (12 Dec 2003 22:13:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Dec 2003 22:13:54 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Dec 12 23:13:51 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUvXi-0005k8-00 for ; Fri, 12 Dec 2003 23:13:50 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUvXi-00062s-00 for ; Fri, 12 Dec 2003 23:13:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AUw86-0003jI-RE for emacs-devel@quimby.gnus.org; Fri, 12 Dec 2003 17:51:26 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AUw5G-0001DC-UG for emacs-devel@gnu.org; Fri, 12 Dec 2003 17:48:30 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AUw16-0005kB-2I for emacs-devel@gnu.org; Fri, 12 Dec 2003 17:44:43 -0500 Original-Received: from [64.246.52.22] (helo=ns5.tangramltd.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AUw15-0005iu-Eu for emacs-devel@gnu.org; Fri, 12 Dec 2003 17:44:11 -0500 Original-Received: from 80-235-40-58-dsl.mus.estpak.ee ([80.235.40.58] helo=mail.jurta.org) by ns5.tangramltd.com with esmtp (Exim 4.20) id 1AUv3V-0004cH-0M; Fri, 12 Dec 2003 23:42:37 +0200 Original-To: karl@freefriends.org (Karl Berry) In-Reply-To: <200312121424.hBCEO6V06218@f7.net> (Karl Berry's message of "Fri, 12 Dec 2003 09:24:06 -0500") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns5.tangramltd.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jurta.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 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:18661 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18661 karl@freefriends.org (Karl Berry) writes: > Seems anchors are useful only for making references to them, not for > selecting them from completion list. > > I don't see any a priori reason to suppose it's not useful to "g"o to an > anchor. One document's anchor is another document's node. (I mean, the > division into nodes vs. subnode positioning via anchors is a judgement > call, not an absolute fact.) > > That said, I don't feel terribly strongly about whether "g" includes > anchor names in possible completions or not. Standalone Info does. Since the name of the function bound to "g" is `Info-goto-node' and its documentation says that this function works only with nodes, so I thought that it's more correct to omit anchors from a list of node completions. I see no harm in removing anchors from a node list because all nodes still can be reached by the "g" command. Anchors only provide additional locations within one Info node. When Info file has many anchors it would be undesirable to overfill a node list with names that lead to the same Info node. I think anchors are only useful in references, for instance, as demonstrated recently by Luc: @xref{doc-hyperlinks, , Tips for Documentation Strings}. However, if there is need to go to anchors by selecting their names from a completion list, then possible solution is either to implement an additional command with an anchor completion list or to add anchor names to a completion list of the `Info-index' command because in fact anchors are more like index items than node names. > ... the reference names feature. I still think this feature is > very useful especially for moving from indexes directly to lines > where index items are described. This feature can be replaced > later gradually by anchors as suggested by Luc. > > I don't understand. I thought that this required index entries to be > used as the second or third arg of xrefs, and I am not aware of any > manuals which make xrefs like that. Nor is that how @xref is intended > to be used. Am I confused? Are you somehow implicitly inserting > references to index definitions? Actually I meant not xrefs but menu entries of Info index nodes, for instance, like this: * auto-fill-mode: Auto Fill. Currently, the `Info-index' command (`i') moves point to the place within a node where an index name is defined, but its functional equivalent - selecting an index from index menu still don't move point to the place where an index name is defined. This patch tries to improve this (but now it works only if index entries are selected by the `Info-follow-nearest-node', not by the `Info-menu', this can be implemented later). -- http://www.jurta.org/emacs/