Re: Relating multiple index entries to one table item

[Patrice Dumas]

On Wed, Nov 23, 2022 at 09:31:07PM +0000, Gavin Smith wrote:
> I made this change by adding a new conversion for the 'table_term' type
> in HTML.pm, which outputs the <dt>, so that everything inside the
> 'table_term' (@item, @itemx and @?index) is output inside the <dt>.
> 
> This might be the wrong way of approaching this (hence my not sharing the
> code).  If both @item and @itemx should produce their own <dt>, but they
> are both children of the same 'table_term', then something else would need
> to be done to get the index entries inside one of the <dt> elements.
> 
> It might work if there was some way of controlling the conversion more
> inside 'table_term'.  When I implemented a conversion for 'table_term'
> (by using a line
> 
> $default_types_conversion{'table_term'} = \&_convert_table_term_type;
> 
> along with a new function), the conversion function had the contents
> already converted.

It is also possible to do something when the element is first
encountered, with $default_types_open{'table_term'} = \&_open_table_term_type;
though I am not sure at all that it would help you.

I have not looked hard into this issue, but a possibility is that
modifying the tree may be simpler to implement the change.  In my
experience, and by design, the HTML API is not fit for changing the
tree, the objective of the API is to be able to customize the formatting
of the elements, but for a tree that is given.  The TREE_TRANSFORMATIONS
are much better suited for changing the tree.  As I said, I do not have
really looked at that issue, it is possible that what you want to
achieve cannot be achieved with a different Texinfo elements tree, but
if it could, my feeling is that a tree transformation would be simpler
to implement.  In addition, the speed penalty should not be particularly
important, as the tree is already traversed for other transformations,
it would just be a matter of adding another transformation during the
traversal.

-- 
Pat