Re: Info-index fails on node-name "~/.cvsrc"

[Juri Linkov <juri@jurta.org>]

>> Is that trailing "5." really a valid format?  Not in my mind.
>
>> It would probably be trivial to change it to generate "(line  5)" instead
>> of "5.".  No harm in that, regardless of the deprecation, which I agree
>> with.

Even if it is considered deprecated, I will install a fix.

> AFAIK, index nodes are just normal nodes with a big menu.
> Thus index entries have the same format as menu entries:
>
>      * NAME: LOCATION.  DESCRIPTION
>
> It's just that traditionally index nodes use an empty DESCRIPTION
> and align all the LOCATIONs so it looks like
>
>      * NAME1:                     LOCATION1.
>      * NAME2:                     LOCATION2.
>
> Adding a DESCRIPTION of the form "5." is just as valid as "(line 5)".

Two distinctions between index and menu entries were added recently.
One is getting line numbers from "(line NNN)".  Currently it works
only in Info indexes.  I don't know if it makes sense for menu items
in non-index nodes as well.

Another difference is special handling of periods in index entries,
which now includes all periods to the node name:

     * .cvsrc file: ~/.cvsrc.
                    ========
     * I see no X here.: I see no X here..
                         ================
     * J. Random Hacker: J. Random Hacker.
                         ================

This may not work for menu items.  Currently, most menu items are
safely limited by ::

     * ~/.cvsrc::     Default options with the ~/.cvsrc file
     * I see no X here.::
     * J. Random Hacker::

so there is no problem.  But we might get into trouble with menu
entries with periods like:

     * .cvsrc file: ~/.cvsrc.     Default options with the ~/.cvsrc file.

Since such menu items are very rare (if exist at all), so perhaps we
shouldn't care for them.

> Now if the node has a new special index-tag (can't remember what it looks
> like), maybe things are different, but with old-style index nodes, it looks
> perfectly valid to me.

If I understand correctly, a new index tag ^@^H[index^@^H] is for
determining if an Info node is an index node, _additionally_ to
current checking the node name for the "\\<Index\\>" regexp.

Karl, could you confirm, is a new index tag supposed to work this way:

1. To determine if the current node is an index node, the Emacs Info
reader should first try to match the node name for the "\\<Index\\>"
regexp.  If that fails, then to search for the "^@^H[index^@^H]" tag
in the current node.

2. To find all index nodes in the current Info file, the Emacs Info
reader should first try to find in the Top node's menu a menu item
whose node name matches the "\\<Index\\>" regexp, and look also in
subsequent nodes matching "\\<Index\\>" (this is as it currently
works).  If that fails, then to scan the whole Info file from the top
for the "^@^H[index^@^H]" tag, and look also in subsequent nodes which
contain the "^@^H[index^@^H]" tag.

-- 
Juri Linkov
http://www.jurta.org/emacs/