Re: info: search fails to find string occurrence

[Bruno Haible]

Karl Berry wrote:
>     If the info file is not OK, why did makeinfo not warn about it? 
> 
> I suppose makeinfo should have something like -Wall that warns about
> such things.
>
> I tried warning about periods and colons and such in node names, and
> there are far too many complaints in existing Texinfo files.  In
> practice, the punctuation often does not cause trouble (unfortunately,
> in a way, or the misfeature would never have lasted this long).

"We have a phenomenon which sometimes causes entirely broken .info
files but only sometimes. Since normally it's harmless, let's not
warn about it."

Huh? Hey? What kind of philosophy is this? Would you be happy as a
GCC user if GCC behaved like this?

Since search might not work across the entire .info file, this warning
should be enabled by default.

> I'm a little surprised it does in this case.

Please, can you find out why it is so harmful in this case, and make
the warning conditional on this reason?

If not, then I'm in favour of an unconditional warning. It helps
understanding
  1. that the problem is with the node names (this is not clear at all
     when you try incremental search and the incremental search finds no
     occurrences),
  2. which node names need to be fixed.

See attached <<patchv1>>.


Actually, when looking at info/search.c, the comment of function
skip_node_characters appears to have the answer. It says:

   Note that
   this function contains quite a bit of hair to ignore periods in some
   special cases.  This is because we here at GNU ship some info files which
   contain nodenames that contain periods.  No such nodename can start with
   a period, or continue with whitespace, newline, or ')' immediately following
   the period.

With this info - unsurprisingly - there are no false positives any more, only
one warning:

gnulib-intro.texi:1: Warnung: Node name `Library vs. Reusable Code' contains a 
period followed by whitespace or a closing parenthesis.

See attached <<patchv2>>.


> The only good answer I've been able to see to this longstanding problem
> is to invent a general escaping mechanism in Info files.

That would be the solution to the general problem. But when you look at the
bug report from 5 years ago and this one, you see that it's only about a
node containing the word "vs.". So please follow me into debugging 'info'.

The 'info' program tries to parse the menu line

   * Library vs. Reusable Code::

and while doing this, the function skip_node_characters wants to end parsing
the node name when it sees the period followed by a space. This is pointless!
In a menu, all node names are terminated by a colon. The only places where
a node name is followed by a period and a space or closing parenthesis are
the expansion of @xref and @pref references inline in text. But in this
situation, the second argument to skip_node_characters will be SKIP_NEWLINES,
i.e. newlines_okay=true. So, if newlines_okay is false, there is no need
to test for a period - just wait for the colon. This patch does it, and
it fixes the problem!

<<patchv3>>

Bruno

patchv1
Description: Text Data

patchv2
Description: Text Data

patchv3
Description: Text Data