bug#10784: 23.1; info doesn't follow link in Bison TOC

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 12 Feb 2012 23:15:49 +0200
> Cc: 10784@debbugs.gnu.org
> 
> > | [tim@passepartout ~/src/emacs]$ zgrep 'Secure\?' /usr/share/info/bison.info.gz
> > | * Secure?  Conform?::           Is Bison POSIX safe?
> > | * Secure?  Conform?::           Is Bison POSIX safe?
> > | File: bison.info,  Node: Multiple start-symbols,  Next: Secure? Conform?,  Prev: Implementing Gotos/Loops,  Up: FAQ
> > | File: bison.info,  Node: Secure? Conform?,  Next: I can't build Bison,  Prev: Multiple start-symbols,  Up: FAQ
> > | 11.6 Secure?  Conform?
> > | File: bison.info,  Node: I can't build Bison,  Next: Where can I find help?,  Prev: Secure? Conform?,  Up: FAQ
> > | Node: Secure? Conform?364602
> > | [tim@passepartout ~/src/emacs]$
> >
> > Note the one vs. two spaces between "Secure?" and "Con-
> > form?".  The link works with info (GNU texinfo) 4.13.  The
> > bug is also present in a Emacs snapshot from early February.
> 
> Does this mean that info (GNU texinfo) 4.13 treats a sequence of spaces
> in the names as one space character?

The stand-alone Info reader always, since day one, canonicalized any
whitespace in node names.

> If yes, should info.el do the same

Yes, it definitely should.  And it already does, just not
consistently.  E.g., if, instead of typing RET on that menu line, you
type "m RET", you get to the right node without any error messages.

> with a patch like this:
> 
> === modified file 'lisp/info.el'
> --- lisp/info.el	2012-02-12 20:24:02 +0000
> +++ lisp/info.el	2012-02-12 21:11:33 +0000
> @@ -1025,7 +1025,9 @@ (defun Info-find-node-2 (filename nodena
>  	  (let ((guesspos (point-min))
>  		(regexp (concat "\\(Node:\\|Ref:\\) *\\("
>  				(if (stringp nodename)
> -				    (regexp-quote nodename)
> +				    (mapconcat 'regexp-quote
> +					       (split-string nodename " +" t)
> +					       " +")
>  				  "")
>  				"\\) *[,\t\n\177]")))

I'm not sure this is TRT.  First, we should convert _any_ whitespace,
not just a sequence of SPC characters, to a single SPC.  Second, I
think it would be better to have a single function for this job and
call it from all the places that need to produce a canonical node
name.  I see at least one other place (`Info-extract-menu-node-name')
where we need to do the same, and possibly one more in
`Info-fontify-node'.  If we do this in each place individually, we
will have inconsistent bugs, whereas we want _consistent_ bugs ;-)

Finally, I think the right place to do this is in Info-find-node, not
Info-find-node-2.