Hi, Eli Zaretskii <[email protected]> writes:
> The index entries should precede the first @item, not be after it. Maybe > doing so doesn't work in this case, but you should move the index entries > before the @item/@itemx lines regardless, since otherwise the indexing > commands will not land you where you want. With the following, @table @gcctabopt @opindex Wno-pedantic @opindex Wpedantic @item -Wpedantic @opindex pedantic @itemx -pedantic The index entries indeed take me to the correct location, but, makeinfo generates: <dl class="table"> <dd><a class="index-entry-id" id="index-Wno_002dpedantic"></a> <a class="index-entry-id" id="index-Wpedantic"></a> </dd> <dt><code class="code">-Wpedantic</code></dt> <dd><a class="index-entry-id" id="index-pedantic-1"></a> </dd> <dt><code class="code">-pedantic</code></dt> ... and no clickable anchors. I took a look at the Automake manual, and I noticed that it has to be doing something right, since it generates the exact results I want. The automake manual uses @ftable to get this, and apparently @vtable can do the same. Can this be replicated for custom defined indices? GCC has this major problem mostly with ``@defcodeindex op'', part of it is that matching ``@opindex'' commands get forgotten on occasion (AFAICT), and the other part is that the result isn't great. Trying simply @optable results in unknown commands, and making @gcctabopt command for the existing @table also emit @opindex emits a warning (and bad results). If that can be done, I can write a script to fix up current option tables pretty easily, as well as any potentially bad results from the fact it's a hasty script ;) Thank you in advance, have a lovely day! -- Arsen Arsenović
signature.asc
Description: PGP signature
