Re: Relating multiple index entries to one table item

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'> &para;</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.