[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo)
bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
Fri, 22 Aug 2014 09:36:14 +0300
> From: Vincent Belaïche <address@hidden>
> Cc: address@hidden
> Date: Fri, 22 Aug 2014 00:23:44 +0200
> During the discussion on address@hidden concerning texinfo
> bug#43042, I received the following comment from Gavin Smith:
> > I don't think it is actually the case that references should use
> > normalized whitespace. For example, there is the following in the bash
> > manual, node "Shell Operation":
> > 3. Parses the tokens into simple and compound commands (*note Shell
> > Commands::).
> > Here we have a newline and initial line indent in the middle of the
> > node name "Shell Commands", but following this cross-reference works
> > fine.
> I a nutshell, there are cases of node references where the info viewer
> is not bothered by internal multiple spaces (this cross reference inside
> bash manual), and other cases where the info viewer cannot handle it
> (the case of node "(texinfo) @- @hyphenation" pointer in menu entry of
> upper node).
Emacs already does all that, of course. Just not in the case of the
menu entries, where the node names are not expected to span more than
> So, on second thoughts, I am thinking in the end that for consistency,
> the info viewer not only should, but also _must_ be corrected.
As I said, maybe. But the fact is that the _Texinfo_source_ of the
Texinfo manual uses different amounts of blanks in this node's name.
So line breaking and filling in the Info file is not the issue here.
> I am even speculating that in the case of the manual menu entry,
> probably it was intentional to put more spaces for the entry to read
> better (as @- and @hyphenation are two different commands, isn't it a
> good idea to put a little more space between them).
The problem is _inconsistency_, not extra blanks. The number of
blanks should have been consistent in all the uses of this node name.