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

[Christopher Dimech]

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" <pertusus@free.fr>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "help-texinfo gnu" <help-texinfo@gnu.org>
> 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
>