Re: @menu puts too many restrictions to produce the .info file

[Patrice Dumas]

On Wed, Oct 21, 2020 at 12:21:25PM +0100, Gavin Smith wrote:
> (switching to bug-texinfo mailing list)
> 
> On Tue, Oct 20, 2020 at 10:46:06PM +0200, Patrice Dumas wrote:
> > On Tue, Oct 20, 2020 at 04:53:11PM +0100, Gavin Smith wrote:
> > > 
> > > Possibly, @novalidate was supposed to do this, as well as checking
> > > cross-references:
> > > 
> > > https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Pointer-Validation.html
> > > 
> > > > Instead, makeinfo checks that the tree constructed from the
> > > > document’s menus matches the tree constructed from the sectioning
> > > > commands. For example, if a chapter-level menu mentions nodes n1 and
> > > > n2, in that order, nodes n1 and n2 must be associated with @section
> > > > commands in the chapter.
> > > 
> > > However, it doesn't appear to work fully.  All the warnings/errors
> > > are still present with @novalidate or --no-validate.  @novalidate
> > > may also do something slightly different with texinfo.tex (stops
> > > auxiliary files from being opened).  It might be worth checking what
> > > @novalidate did with older versions of makeinfo to see if there
> > > is a regression.
> > 
> > I do not think that we should do that.  I think implementing what is in
> > the documentation is more important than being in line with what was
> > before.  And even more important is to specify correctly in the
> > documentation what it should do.
> 
> The other variable that affects whether warnings are given is SHOW_MENU,
> but this is not documented.  I wonder if menu-related errors should
> always be given regardless of SHOW_MENU.

I don't think so, the idea is that if menu are not used at all in the 
output, there is no point in showing any menu related error.

> At present @novalidate only turns off errors about wrong links (in
> cross-references or menus), but doesn't affect errors about the
> document structure.  I think it would be simpler to keep it this
> way.  (If I understand correctly, the structuring errors only
> came in with Texinfo 5.)

Ok.  The more I think about it, the more I agree that it should be left
that way, ie that novalidate only cares about errors that are real 
errors in every case, not errors of consistency.  This means that the
"Pointer Validation" node should be modified to separate what
novalidate checks, I think it is only the point 1:

  1. If a 'Next', 'Previous', or 'Up' node reference is a reference to a
     node in the current file and is not an external reference such as
     to '(dir)', then the referenced node must exist.

So the part at the beginning about novalidate should only be associated
with that point.

> > > @novalidate seems to have been intended as an ad hoc, temporary
> > > insertion in a file while it was being worked on, rather than to
> > > be a permanent part of the file.
> > 
> > I am not so sure about that.  If it is so, it should be documented.
> 
> With TeX output it doesn't even output the page numbers for
> cross-references, so it couldn't be a permanent part of the file,
> at least when processing with TeX.

Actually, I read the doc and it is indeed documented as being temporary.

As a side note, @novalidate also suppress warnings of nodes with the
same normalized name, but different Texinfo code strings.

-- 
Pat