anymore, eg the above example tells you that there is no node
"yes invocation."
Oops, of course.
If you don't have a genius idea how to overcome this problem
My only idea is far from genius -- Emacs Info must have solved this
somehow (since it can find Matching vs. Searching,
Hi Karl!
On Sa, 28 Jan 2006, Karl Berry wrote:
> What was the reason that node names cannot contain the sequence
> ". " or ".\t" etc
> ??
>
> The only thing I can think of is that it is somehow related to the dir
> file, which contains entries like this, with a period followed
On Fre, 27 Jan 2006, Karl Berry wrote:
> Something related: The most puzzling, even for me, error/bug/strangeness
> is that info jumps to the man page of "top" when you enter
> info ./notexistingfile
> instead of going to the top node or giving an error message ;-)
>
> Unre
> Date: Fri, 27 Jan 2006 23:16:15 +0100
> From: Norbert Preining <[EMAIL PROTECTED]>
> Cc: bug-texinfo@gnu.org, [EMAIL PROTECTED]
>
> Ahh, bingo... I found the problem. It is really a parsing, and only in
> the case when
> ". "
That's because this string can end a node name in a menu. See
On Fre, 27 Jan 2006, Karl Berry wrote:
> I briefly grepped through the source, and I think (no promises) the
> relevant code might be the horribly ugly test in skip_node_characters in
> search.c, if you feel like messing with it for a few minutes ...
Hmm it seems that you are right:
At the end of
Can you tell me in which function the scanning is performed, I can take
a look into the code.
Ugh, when I've looked at this stuff before, it seems to be spread all
over. Most of the relevant code is in nodes.c, I think, e.g.,
info_get_node.
(And maybe once I learn how to debug an int
GNU. Free.Document.License
and boing, I cannot go the the node.
Ah!
Is it documented somewhere that node names *SHOULD NOT* contain "."?
Yes, in the Texinfo manual.
If yes, we can also forget about this and close this bug, because info
is not used according to the do
> So my suggestion is, try getting rid of that test, and see if things
> basically work (and "matching vs. searching" can be found). If it looks
Ok, so you would suggest trying out:
--- search.c.orig 2006-01-28 23:03:18.0 +0100
+++ search.c2006-01-28 23:05:00.0 +0100
@@
Hi Karl!
On Fre, 27 Jan 2006, Karl Berry wrote:
> Yes, it might explain it, except that those jump indications are
> correct, as far as I can tell.
Ok,
> That's why I said it is necessary to have more files.
>
> My guess is a parsing problem in standalone info. Otherwise I'd expect
> all
On Fre, 27 Jan 2006, Karl Berry wrote:
> My guess is a parsing problem in standalone info. Otherwise I'd expect
> all the nodes to be unfindable, not just the one with the period in the
> name.
Ahh, bingo... I found the problem. It is really a parsing, and only in
the case when
". "
is in
What was the reason that node names cannot contain the sequence
". " or ".\t" etc
??
The only thing I can think of is that it is somehow related to the dir
file, which contains entries like this, with a period followed by
whitespace:
* Bash: (bash). The GNU
Hi Karl!
Good to hear from you, hope you are doing well in the new year!
On Don, 26 Jan 2006, Karl Berry wrote:
> 146133 and 151850 Matching vs. Searching
> --
> If you take a info file which is split into different files, and there
>
It seems that the generation of the info files, especially with the
jump indications at the end of the first file, are improperly
created. WOuldn't this explain the problem?
Yes, it might explain it, except that those jump indications are
correct, as far as I can tell.
That's why
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 che
14 matches
Mail list logo