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.
Message is intended to start a discussion on improving some aspects for those intending to do non-trivial work in texinfo. And start tackling some of them. Let's start with a useful case. Let's forget about subsections for now. Test 1: Suppose I change the last @node to @anchor. Makeinfo will complain that menu and sections are not in order. If you try to mouse click on the menu at the location of the @anchor, the Anchor Reference will not work. --------------------- Christopher Dimech Chief Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Tuesday, October 20, 2020 at 3:03 PM > From: "Patrice Dumas" <[email protected]> > To: "Christopher Dimech" <[email protected]> > Cc: "help-texinfo gnu" <[email protected]> > Subject: Re: @menu puts too many restrictions to produce the .info file > > On Tue, Oct 20, 2020 at 02:49:28PM +0200, Christopher Dimech wrote: > > I wish to point out that @menu puts a lot of restrictions on running > > makeinfo. > > > > > > Do you have a use case in which this would not be an error: > > 1. Having an unreferenced node > > 2. lacking some item in the Menu > > 3. Not having same order in menu as in Sectioning > > This one seems to me to be ok, @node and @anchor should be unique, it is > an intended feature: > > 4. Menu complains about @anchor > > 5. Menu complains of @sebsectioning > > > > I do get use cases where the menu is there to help the user > > towards a particular direction. However when I produce > > documentation in Pdf I want it too look are an ordered manual. > > > > There are many reasons why a person would want a menu that differs > > from the sectioning. > > I agree with you on 2, 3, and 5. In general those warnings are ok, as > these are likely to be mistakes, but I agree that the user may want > menus structures to be different from the tree structure and suppress > the corresponding warnings somewhat selectively. @novalidate > and --no-validate could be of use in that case, but it may also be too > broad. > > One possibility could be to add a customization variable, like > ALLOW_NON_TREE_NODE_STRUCTURE > > -- > Pat >
