On Sun, Jun 22, 2025 at 10:15:23PM +0100, Gavin Smith wrote: > On Sun, Jun 22, 2025 at 10:59:07PM +0200, Patrice Dumas wrote: > > On Sun, Jun 22, 2025 at 06:53:42PM +0100, Gavin Smith wrote: > > > @c Getopt and argp start at the @section level so that there's > > > @c enough room for their internal hierarchy (mostly a problem with > > > @c argp). -Miles > > > > > > As the comment says, "Getopt" is a @section although its superior node > > > is a @subsection. > > > > > > This could be an example of incorrect sectioning levels being the problem, > > > rather than an issue with menus. At the moment the only idea I have is > > > to also warn about the node up pointer mismatch at the same time. > > > > I do not really understand the comment explaining why Getopt and argp > > start at the @section level, I do not get what "enough room for their > > internal hierarchy" means, so it is not clear to me why the Glibc people > > want that structure. > > Getopt is listed in the menu for "Parsing Program Arguments" which is > a @subsection. This means that Getopt should be a @subsubsection. Getopt > itself has inferior nodes, like "Using Getopt". However, there is no > sectioning command below @subsubsection (no "@subsubsubsection", etc.). > That's what they mean with "not enough room."
Ok, I get it, thanks. In that specific case, a possibility could be to have something in the Texinfo language to get a correct output, as having a node structure different from the sectioning structurer is not really wanted as such, but used as a trick to get a correct output. That being said, I can't see any obvious way to do that in a way that would integrate well with the current language. If there were only @node that would be possible, but for sectioning commands nothing seems easy. In DocBook, this kind of structure is achieved by having the possibility to nest <section> recursively up to unbounded depth. It could be possible to nest block commands in Texinfo to obtain the same kind of effect, but that would be quite inconsistent with the language usual design in which line commands (@node, sectioning commands) rather than block commands delimitate sections. Maybe an option could be to have a line @-command like @xrefname that would use the structure of th eassociated node to determine the sectioning level rather than the other way around. For example in the following example, the @nodesection would be equivalent to a @subsubsubsection: @node my node @subsubsection subsub @menu * down:: @end menu @node down @nodesection Down there -- Pat
