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

[Christopher Dimech]

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

C* If occurs very frequently that @menu giver me lot of grief, unlike when
I use texi2pdf.  When a reference is not reached, one gets undefined in the
output, which I can then go and fix.  It is much better fixing problems
that way, or disregarding them for a while, as I write my manual.  It is
customary for me to leave sections around that are not yet fully developed,
and still undecided one sectioning and node names.  So all the checking
for me to get the info file gets very time consuming. 

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

Fully agree


---------------------
Christopher Dimech
General 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 27, 2020 at 9:40 AM
> From: "Patrice Dumas" <pertusus@free.fr>
> To: "Gavin Smith" <GavinSmith0123@gmail.com>, "Christopher Dimech" 
> <dimech@gmx.com>, bug-texinfo@gnu.org
> Subject: Re: @menu puts too many restrictions to produce the .info file
>
> 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
>