On Tue, Nov 22, 2022 at 09:11:58PM +0000, Gavin Smith wrote: > > 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.
Maybe not important if there are other changes afterwards, but with the change, in HTML, the result is now invalid, as the index entries end up not associated with the index term <dt>, but after the index term. This is not correct, as the outer <dl> should only contain <dl> and <dt>. It may not be an issue at all if you do further changes, or it could be an issue to be solved in the HTML converter. > 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. Sure, except that for that case, I do not think that we can decide what is the best output for the existing usage, as some users could want index entries merged with @ftable @item while some other may not. Adding a new language construct allows to make everyone happy. The current @ftable keeps not having index entries merged with @item, while they are in the new construct, and in a more explicit/controlled way. Of course this should be weighted against one more new language construct, but to me, automatically merging one preceding/following index entry to @ftable @item is not right. -- Pat
