On Tue, Nov 22, 2022 at 10:23:24PM +0100, Patrice Dumas wrote: > Maybe not important if there are other changes afterwards, but with the > change, in HTML, the result is now invalid, as the index entries end up > not associated with the index term <dt>, but after the index term. This > is not correct, as the outer <dl> should only contain <dl> and <dt>. It > may not be an issue at all if you do further changes, or it could be an > issue to be solved in the HTML converter.
I'll check this output and see I can change it to be valid again. > > 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.
