RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'

[Vincent Belaïche]

Hello Eli, Gavin, Patice, & Karl.

Looping also through Patrice Dumas and Karl Berry and texinfo-bug
list.

Useful links:

http://savannah.gnu.org/bugs/?43045
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18308

Answers & comments below:

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

[...]


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

I have checked that in the case of the node line:

File: texinfo.info Node:<node name> ...

the texi2any compiler does correctly the multiblank collapsing.

Basically, trying to recap, if I get it, the work split that you (Eli)
are suggesting between info viewer and texi2any compiler is as follows:

- texi2any must collapse multiple blanks in node names *everywhere*, but
  it is still allowed to break and indent a node name containing a blank
  accross a line in the case of a note.

- info viewer must handle node name split accross lines, but it does not
  need to make multiblank reduction in other-cases

Now, if the above is agreable, then in the case of our problem this
would imply that when texi2any meets that kind of menu entry

* NODE    NAME:: SOME TITLE

It must convert it to within the info file:

* NODE    NAME: NODE NAME. SOME TITLE


Eli:
1) do you agree on my re-caping and suggestion ?

2) do you think that all the same, robustifying the info viewer in the
   case of menu entry has some benefit --- after all this allows:
   2.1) to cope with job done by earlier versions of makeinfo in this
        corner case
   2.2) to have very slightly smaller info file still in this corner case

Gavin & Patrice, do you agree on my suggestion how to evolve texi2any
and stand-alone info viewer ?

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

I think that the root of that _inconsistency_ problem is that when you
write the following:

* NODE    NAME:: SOME TITLE

"NODE    NAME" has two meanings:

1) it is the menu label, ie what the user will see, so you are not
   allowed to collapse blanks, because this would change what the author
   want to be diplayed to the user

2) it is also the node pointer, so in this case you have to collapse 
   blanks.


Karl: don't you think that *ALSO* the manuel should be changed to be
written as  

* NODE    NAME: NODE NAME. SOME TITLE

In the case of info node `(texinfo) @- @hyphenation'.

Maybe it is not such a good practice to write it the other way round,
because if the author has some intention to display things in some
specific way, then for maintainability that should be explicit in the
way as it is written in the texinfo code.

   Vincent.