On Tue, Feb 23, 2021 at 01:30:41AM +0100, Patrice Dumas wrote: > Hello, > > It seems confusing to me have %formats_table in texi2any.pl and also access > to converter default configuration values in %converter_defaults, which > are used in parser for example. The 'module' key, 'texi2dvi_format', > and also for formats that do not have an associated converter, for > instance 'parse' and 'structure' putting defaults in %formats_table could > make sense, but for the formats with a converter module I would suggest > putting > the information in converters %default. > > Anybody with another advice on that matter?
This isn't something I've understood in great depth (I had to lookup where %converter_defaults was defined, as far as I can tell there is no such hash, but there is a converter_defaults function defined in Texinfo/Convert/Converter.pm which returns a hash), but it seems to me that the purpose of the %formats_table in texi2any.pl is to store information about what should be done for each output format in texi2any.pl itself. I think the %formats_table is quite easy to understand and see what each part of it is used for. If you were to put data inside %defaults in Texinfo/Convert/HTML.pm, then this would only make sense if it was going to be used in HTML.pm itself. I'm not sure which values you were thinking of moving away from %formats_table, but for example looking at the 'internal_links' value, it's easy to search texi2any.pl for "internal_links" and find the code where this applies. (I hadn't actually looked up what this was when I did it.) I looked it up, and it appears to be only for HTML output, so this would make sense to move all the code for this to HTML.pm (I haven't looked at what the code does so don't know for sure if this would be sensible). As 'internal_links' was only used for HTML, it's more straightforward, but where it is used for several like 'nodes_tree' or 'move_index_entries_after_items' it might make sense to keep this in texi2any.pl, especially where it specifies for structural transformation or annotation that is not format-specific (calling functions in Texinfo/Structuring.pm or Texinfo/Transformations.pm). 'split' is a different case to this again, as splitting means something different for every output format. It should be considered on a case-by-case basis. As an aside, I have found the configuration a bit confusing in the past with the distinction between parser options and converter options (and what else I don't know). The contents of %defaults looks like mostly user-settable configuration variables so we'd have to consider if anything put in there was to be user-settable.
