Re: Relating multiple index entries to one table item

[Patrice Dumas]

On Sat, Nov 26, 2022 at 03:58:59PM +0000, Gavin Smith wrote:
> 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 do not think that this is actally needed.  I will try to do it with
_open_table_term_type only, and see if it is ok.

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

Ok.

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

The parse tree is sensible as it is now (or as you changed it), but tree
transformations suited to output formats may make sense, and be only
valid for some output formats.  In our case, in HTML there is no
constraint on having only one line in a <dt>, so it is possible that a
tree that makes sense for HTML, with index entries being put in a @item,
or in the table_term type container, while in other formats where table
@item must be on a line it would not be possible.

That being said, it seems to me that for that case your change is good,
and there is no need for a transformation, which is better.

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

It may not be necessary either, maybe this could change in the future,
but in the texinfo.tex PDF the link is to the page, not to the precise
entry, and even if I am mistaking and it is to the precise location of
the entry, I think that in pdf not being as precise as in HTML is not
necessarily bad.  Also it seems to me that in HTML we care more about
the nesting of elements than in PDF.  The HTML result can be further
used by javascript/CSS such that the constraints are not the same.

-- 
Pat