What gets me most frustrated is that when I introduce @bye somewhere within the document, makeinfo goes nuts. @bye is a great command to use when texi2pdf is unsuccessful so I may investigate. Makeinfo does not give me that possibility. If I remove the menu but there are references in the document, the info file is not generated.
> Sent: Tuesday, October 27, 2020 at 9:40 AM > From: "Patrice Dumas" <[email protected]> > To: "Gavin Smith" <[email protected]>, "Christopher Dimech" > <[email protected]>, [email protected] > 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 >
