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

[Gavin Smith]

The simplest solution for Christopher's document is to delete
the menu altogether: delete the four lines

@menu
* Intactv-Function::  Interactive Functions.
* Tpsw-Cmd::          The Tpsw Interactive Command with Numeric Arguments.
@end menu

and the errors all go away.

On Tue, Oct 20, 2020 at 03:43:23PM +0200, Patrice Dumas wrote:
> On Tue, Oct 20, 2020 at 03:31:10PM +0200, Christopher Dimech wrote:
> > It should not be assumed that the author made mistakes. At least
> > not problems with how one structures the document. Because when
> > using texi2pdf all of that is acceptable.
> 
> On the one hand I agree that it may be annoying for a user to have
> warnings for intentionnal and valid code, on the other hand, most of the
> users are happy with the tree structure and it is indeed a mistake when
> the menu structure does not follow the tree structure.  So I think that
> using a customization variable is ok to begin with, and it could even be
> decided later that it is on in the default case.  But let's see if Gavin
> says something on that.

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.

@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 don't like the idea of requiring variables to be set for a file to be
processed correctly.  It would be better if there was something in the
file itself to indicate how menus/sectioning should be interpreted.
Due to the effect on texinfo.tex, @novalidate can't have this role,
though.

The menu/sectioning code is already quite complicated, so adding
another customization variable affecting this would be a bad idea.

I tried @detailmenu to try and get a menu that wouldn't be validated,
but this is not enough: although the contents of a @detailmenu
block are not subject to validation themselves, @detailmenu has to
be nested within a @menu block, and if that @menu block is there,
validation happens.

The warnings and errors go away if you specify node pointers explicitly.

For example, instead of

@node Intactv-Function

have

@node Intactv-Function,,,

After all, since you have not said what the Next/Prev node should be
in the first case, makeinfo has to determine it somehow, and it is a
problem if the menus and apparent section structure contradict each other.

If an author wants to have irregular menu or node structures for some
reason (I haven't made sense exactly of what Christopher is doing
with his documents) then they could use explicit node pointers,
specifying Next/Prev/Up for each node.