[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Info enhancements

From: Juri Linkov
Subject: Re: Info enhancements
Date: Fri, 12 Dec 2003 23:38:56 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

address@hidden (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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]