bug-gnu-emacs
[Top][All Lists]
Advanced

[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)


From: Eli Zaretskii
Subject: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
Date: Fri, 22 Aug 2014 09:36:14 +0300

> From: Vincent Belaïche <Vincent.b.1@hotmail.fr> 
> Cc:  18308@debbugs.gnu.org
> Date: Fri, 22 Aug 2014 00:23:44 +0200
> 
> During the discussion on bug-texinfo@gnu.org 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
one line.

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]