* bug#10784: 23.1; info doesn't follow link in Bison TOC
@ 2012-02-10 22:06 Tim Landscheidt
2012-02-12 21:15 ` Juri Linkov
0 siblings, 1 reply; 4+ messages in thread
From: Tim Landscheidt @ 2012-02-10 22:06 UTC (permalink / raw
To: 10784
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
- (info "(bison)") ;; version 2.4.1
- search for TOC item "Secure? Conform?"
- press RET
- => "No such node or anchor: Secure? Conform?"
(Probably) relevant bits from the info file:
| [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.
In GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.6)
of 2010-04-01 on x86-01.phx2.fedoraproject.org
Windowing system distributor `The X.Org Foundation', version 11.0.10603901
configured using `configure '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xft' '--with-xpm' '--with-x-toolkit=gtk' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-bu
ffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: de_DE.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#10784: 23.1; info doesn't follow link in Bison TOC
2012-02-10 22:06 bug#10784: 23.1; info doesn't follow link in Bison TOC Tim Landscheidt
@ 2012-02-12 21:15 ` Juri Linkov
2012-02-13 17:15 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Juri Linkov @ 2012-02-12 21:15 UTC (permalink / raw
To: Tim Landscheidt; +Cc: 10784
> | [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? If yes, should info.el do the same
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]")))
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#10784: 23.1; info doesn't follow link in Bison TOC
2012-02-12 21:15 ` Juri Linkov
@ 2012-02-13 17:15 ` Eli Zaretskii
2020-09-14 11:50 ` Lars Ingebrigtsen
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2012-02-13 17:15 UTC (permalink / raw
To: Juri Linkov; +Cc: 10784, tim
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#10784: 23.1; info doesn't follow link in Bison TOC
2012-02-13 17:15 ` Eli Zaretskii
@ 2020-09-14 11:50 ` Lars Ingebrigtsen
0 siblings, 0 replies; 4+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-14 11:50 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 10784, tim
Eli Zaretskii <eliz@gnu.org> writes:
> 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.
[...]
> 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.
The bug was still present on the trunk, so I've now done this.
> 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 ;-)
Indeed. I had a quick skim-through of Info-fontify-node, but it's a 422
line function, and I'm not sure what bit should be changed here...
> Finally, I think the right place to do this is in Info-find-node, not
> Info-find-node-2.
Done.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-14 11:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-10 22:06 bug#10784: 23.1; info doesn't follow link in Bison TOC Tim Landscheidt
2012-02-12 21:15 ` Juri Linkov
2012-02-13 17:15 ` Eli Zaretskii
2020-09-14 11:50 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.