info goto node with dot

[Karl Berry]

Hi Norbert,

Back on this from November ...

    146133 and 151850       Matching vs. Searching
    ----------------------------------------------
    If you take a info file which is split into different files, and there
    is a node containing a `.', jumping to this node does not work.
    I checked this with 4.8 and it is still present there.
    (I have a rather long example here, if you want I send it to you)

In my tests, splitting into different files doesn't matter.  For
instance, the a2ps, gettext, and cvs manuals have node names containing
"." in subfiles, and (oddly enough) both standalone info and emacs could
find them.

    Here we have some very strange problem: I don't know wether you are
    interested in taking a look at this. The problem is that the *INFO*
    files are *generated* from html pages, not via texi files. THe actual
    road is:
            TeX Document -> latex2html -> HTML Document -> python script
                    -> info files

    I assume that the generation of the info files contains a bug.

I don't see anything obviously wrong in those (python2.1-lib) info
files, so unfortunately I can't quickly blame the info generation code :).

I notice that the info reader does recognize the node, in that it shows
up in the completion list.  I also notice that I cannot reach the node
by other means, e.g., traversing the menus (string services, re), I get
the "interesting" error:
  Matching vs. Searching: No such file or directory

The only idea that comes to my mind is that perhaps it's because the
*filename* also contains a "." (the "2.1").  Can you try making the
python docs without that dot, and/or making a test file with a dot, and
see what happens?

    BUT: the emacs info reader actually *can* jump to the 
            "Matching vs. Searching"
    node. So either the emacs-info reader add some kind of magic or there is
    a problem in info.

Clearly there is some difference, but bugs in standalone info are the
lowest priority for me.  Furthermore, node names are also documented not
to contain "." -- although this is a ridiculous restriction, it is one
of long standing, and it's not easy to fix in full generality.

So unless some lightning strikes or another developer appears, I can't
hold out a lot of hope on this one, sorry ...

Thanks,
Karl