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
