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

[Patrice Dumas]

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.

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

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

I do not think that the issue here is the processing, only the messages.

> The menu/sectioning code is already quite complicated, so adding
> another customization variable affecting this would be a bad idea.
> 
> 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.

That is a good point.  However, it is not clear to me that it is a
problem if the Next/Prev and the menus are different, which means that
it could be acceptable for the tree structure and the menu structure to
be different even if the Next/Prev node are determined by the section
tree structure.  To state it differently, maybe it should be possible to 
select menu or sections to be the source of the Next/Prev, and have the 
Next/Prev structure not consistent with the one that is not used to
setup the Next/Prev.  I'll have to look at the code to remember how
things are done.

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

I think that the menu structure could be somehow disconnected from the
node structure.  It seems to me that as long as a node is reachable, it
is ok, even if the node Next/Prev/Up structure is not consistent with
the menu structure.

-- 
Pat