From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#10784: 23.1; info doesn't follow link in Bison TOC Date: Mon, 13 Feb 2012 19:15:30 +0200 Message-ID: <83r4xyy7rh.fsf@gnu.org> References: <87fweflpmi.fsf@mail.jurta.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1329153406 21169 80.91.229.3 (13 Feb 2012 17:16:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Feb 2012 17:16:46 +0000 (UTC) Cc: 10784@debbugs.gnu.org, tim@tim-landscheidt.de To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 13 18:16:45 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RwzW8-0007fz-BR for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Feb 2012 18:16:44 +0100 Original-Received: from localhost ([::1]:55615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwzW7-0004gf-CO for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Feb 2012 12:16:43 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwzW1-0004gP-B4 for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2012 12:16:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RwzVu-0006Si-VP for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2012 12:16:37 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwzVu-0006Se-Tn for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2012 12:16:30 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RwzXN-0002oF-TL for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2012 12:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Feb 2012 17:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10784 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10784-submit@debbugs.gnu.org id=B10784.132915344710748 (code B ref 10784); Mon, 13 Feb 2012 17:18:01 +0000 Original-Received: (at 10784) by debbugs.gnu.org; 13 Feb 2012 17:17:27 +0000 Original-Received: from localhost ([127.0.0.1]:39132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RwzWo-0002nI-Da for submit@debbugs.gnu.org; Mon, 13 Feb 2012 12:17:26 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:32796) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RwzWl-0002n5-8C for 10784@debbugs.gnu.org; Mon, 13 Feb 2012 12:17:24 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LZC00L00D1BLM00@a-mtaout22.012.net.il> for 10784@debbugs.gnu.org; Mon, 13 Feb 2012 19:15:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.150.51]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LZC00K24D9RLKF0@a-mtaout22.012.net.il>; Mon, 13 Feb 2012 19:15:28 +0200 (IST) In-reply-to: <87fweflpmi.fsf@mail.jurta.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:56855 Archived-At: > From: Juri Linkov > 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.