On Mon, Nov 21, 2022 at 10:04:16PM +0100, Patrice Dumas wrote: > On Mon, Nov 21, 2022 at 08:49:34PM +0000, Gavin Smith wrote: > > My current work is at the bottom of the email. This will need more testing > > and also implementing in the XS parser, so it will take me at least few > > days to > > finish. > > It could also be a tree transformation that is applied after the > tree parsing. > > > The idea is to put the index entries in the 'table_term' element rather > > than 'table_item', and in the transformation in Texinfo::Common, > > to reorder inside table_term to put index entries first, taking the > > first index entry that occurs as the copiable anchor. So > > > > @table @asis > > @item -Wpedantic > > @itemx -pedantic > > @vindex pedantic > > @vindex Wpedantic > > @vindex Wno-pedantic > > aaaaa > > > > bbb > > @end table > > > > produces > > > > <dl class="table"> > > <a class="index-entry-id" id="index-Wpedantic"></a> > > <a class="index-entry-id" id="index-Wno_002dpedantic"></a> > > <dt id='index-pedantic'><span>-Wpedantic<a class="copiable-link" > > href='#index-pe > > dantic'> ¶</a></span></dt> > > <dt>-pedantic</dt> > > <dd><p>aaaaa > > </p> > > <p>bbb > > </p></dd> > > </dl> > > > > Does this seem ok? > > The repositioning of index entries look ok, but automatically > associating one to the table_term does not look clearly ok to me. In > some cases it could what the user wanted, but in other cases not.
I've committed a change to move the index entries to the 'table_term' element, and updated the code in the 'relate_index_entry_to_table_entry' tree transformation to look for an index entry in the new place. My intention is that table items will be associated with the same index entries as before. This was a preliminary change to allow other changes afterwards. I left out the code to do any reordering of index entries and @item/@itemx lines. This could be done in a separate transformation, if this would be clearer. The changes to the test results seemed acceptable, but I would like to check which tests check combinations of @item/@itemx/@?index and add more tests if needed. > I think that it would be better to separate the issue of index entries > repositioning from the issue of having a table command associated to > another index type, and to have an index entry not matching the @item > argument. > > Could be for example > > @itable > @item v, pedantic, -pedantic > > @end itable I think deciding on the right output for the existing usage and implementing such is more important than devising and implementing new language constructs.
