Re: Project bloat report

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.