On Wed, Jan 28, 2026 at 09:58:08AM +0100, Patrice Dumas wrote: > On Fri, Jan 23, 2026 at 11:25:37PM +0100, Patrice Dumas wrote: > > > That all sounds fine but I would like to keep "required" as it is. It's > > > fine to add another option. I suggest "requiredifenabled". The "enabled" > > > part could refer to the result of running 'configure' or the TEXINFO_XS_* > > > variables. > > > > Ok, I'll use that. > > I implemented something. > > > > I've got in mind to think about how to report status of XS code better > > > for the test suite, but haven't been able to get to this yet. > > > > My current idea with the requiredifenabled possibility is to use it such > > that there is no need to report anything, if the state is no exactly the > > expected state, there would be a failure. > > I failed to do that. For modules that are not replaced as a whole and > have overriden functions, right now it is not easy to avoid functions to > be overriden in advance. This could be changed, but there is also the > possibility to replace whole modules that could be more relevant, as it > would simplify XS loading and also make clearer which functions are > overriden.
Yes, it would be good to have less of this in source files: > "Texinfo::Convert::HTML::command_id" > => "Texinfo::Convert::ConvertXS::html_command_id", > "Texinfo::Convert::HTML::command_contents_target" > => "Texinfo::Convert::ConvertXS::html_command_contents_target", > "Texinfo::Convert::HTML::footnote_location_target" > => "Texinfo::Convert::ConvertXS::html_footnote_location_target", > "Texinfo::Convert::HTML::footnote_location_href" > => "Texinfo::Convert::ConvertXS::html_footnote_location_href", > "Texinfo::Convert::HTML::command_filename" > => "Texinfo::Convert::ConvertXS::html_command_filename", > "Texinfo::Convert::HTML::command_root_element_command" > => "Texinfo::Convert::ConvertXS::html_command_root_element_command", > "Texinfo::Convert::HTML::command_node" > => "Texinfo::Convert::ConvertXS::html_command_node", > "Texinfo::Convert::HTML::_internal_command_href" > => "Texinfo::Convert::ConvertXS::html_internal_command_href", > "Texinfo::Convert::HTML::command_contents_href" > => "Texinfo::Convert::ConvertXS::html_command_contents_href", > "Texinfo::Convert::HTML::_internal_command_text" > => "Texinfo::Convert::ConvertXS::html_internal_command_text", > "Texinfo::Convert::HTML::_internal_command_name" (from HTML.pm.) > I propose to replace more systematically whole modules, and when there > are common Perl parts either put it in the module doing the loading or > in a separate module that would be loaded by the pure Perl module and be > passed for the XS module as an XSLoader init $perl_extra_file. Good idea. > Note that it may be less flexible than overriding, in the (rare) case of > overriden functions in a module depending on different conditions. > > If this is agreed that it is a good idea, I could start doing it a bit > in this release for the modules that have a lot of overrides, but this > is more for the next release. Can you minimise what changes you make before the next release as it may end up being a bigger change than you expected?
