Re: Relating multiple index entries to one table item

[Gavin Smith]

On Thu, Nov 24, 2022 at 12:07:47AM +0100, Patrice Dumas wrote:
> 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 used this, thanks.  I opened <dt> at the 'table_term' so that it
would include any index entries that were inside the 'table_term'.

I still haven't put index entries before the very first
@item in a @table inside the <dt> - I need to do something with the
'before_item' element.

> 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.

Ideally the parser should produce a sensible parse tree itself and this
would be sufficient for the conversions, without the need for any
"transformations", although this may not be possible.

One concern is matching the behaviour of the texinfo.tex PDF output -
it's much more difficult to move index entry targets around there.