Re: Relating multiple index entries to one table item

On Tue, Nov 22, 2022 at 09:49:31PM +0000, Gavin Smith wrote:
> > > 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.
> 
> @ftable and @vtable may be treated differently to @table as they provide
> their own index entries.

I actually meant @table in my paragraph above:

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 @table @item while some other may not.
Adding a new language construct allows to make everyone happy.  The
current @table 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 @table @item is not right.

-- 
Pat