On Wed, Mar 04, 2026 at 03:41:41PM +0100, Patrice Dumas wrote: > > - Features of texi2any that could be considered bloat: > > > > * The XML format output with --xml. This is not actually useful > > for anything. > > The Texinfo manual suggests that users might want to use this as a > > starting point for conversion to other formats, but I'd actually > > rather they didn't, as it means that we have to maintain the XML > > converter, and would be better to have the converters built into > > texi2any like the other output formats. > > It's not a huge maintenance burden, except remembering to update > > the DTD when the language changes, and the time spent running > > the tests for XML output, of course. > > I fully agree. The XML output may have been relevant in the past, but > now it is not, and if something similar was to be done nowadays, I think > that it should be done from scratch and be more in line with the current > tree. Or the SWIG interface should be used instead. I would back up a > phasing out of the XML (and associated SXML), and migration of the code > to Example, with removal of --xml option, and removal from the Texinfo > manual. It could stay in Example for more time, though,
I'd be happy with this. > DocBook also seems to be much less used nowadays. Probably still > relevant. I think we should keep the DocBook converter but it would be fine to keep in Perl and require a Perl interpreter to run it, either through XS or SWIG. > > On a lesser scale of problem, the API documentation takes quite a long > > time to build and upload to the GNU website when doing a new release > > because there is so much of it. > > I think that it is the internal API documentation you are describing > here. The texi2any HTML customization API is only in texi2any_api.texi. Yes, it was the texi2any_internals documentation I was thinking of. > Something you did not describe, and, in my opinion, could be simplified > is the possibility to have XS extensions loaded at different steps. > It is relevant when the XS extensions have just been done, but in the > long run, I think that we should only have two possibilities, pure Perl > or all the XS extensions + Perl for the remaining. I think that the > fine grained level of control permitted by the TEXINFO_XS_PARSER, > TEXINFO_XS_STRUCTURE and TEXINFO_XS_CONVERT variables could be removed > in the long-term. I agree with this. I think all three of these variables could be removed as soon as it is convenient.
