bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christopher Dimech
Subject: Re: @menu puts too many restrictions to produce the .info file
Date: Tue, 27 Oct 2020 10:07:04 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]