Re: Further reducing special case code for XS structuring

2024-04-05 Thread Gavin Smith
On Fri, Apr 05, 2024 at 11:02:14PM +0200, Patrice Dumas wrote: > > I've committed a change to remove the $no_build parameter but not the > > $no_store parameter. > > It seems to me that the changes are no complete, to me the _get_parser_info > $no_build argument should be removed too, and the

Re: Further reducing special case code for XS structuring

2024-04-05 Thread Patrice Dumas
On Fri, Apr 05, 2024 at 02:40:41PM +0100, Gavin Smith wrote: > On Fri, Apr 05, 2024 at 12:20:19AM +0200, Patrice Dumas wrote: > > I am not sure that no_store is used, but I think that it should be > > considered completely separately from no_build and the on-demand Perl > > structures build, as it

Re: Further reducing special case code for XS structuring

2024-04-05 Thread Gavin Smith
On Fri, Apr 05, 2024 at 12:20:19AM +0200, Patrice Dumas wrote: > I do not think that having the same interface for XS and pure Perl is > important. It could even make clearer what is going on in XS. What is > important is to have a code that is easy to understand as a whole in my > opinion. > >

Re: Further reducing special case code for XS structuring

2024-04-04 Thread Patrice Dumas
On Thu, Apr 04, 2024 at 10:23:13PM +0100, Gavin Smith wrote: > I am working on changes for this, but it still doesn't seem right to me, > in the case of XS structuring being on, and XS conversion being off. > > As of commit 5f6800edc (2024-04-03 13:29:19 +0100), in texi2any.pl the > tree is

Re: Further reducing special case code for XS structuring

2024-04-04 Thread Gavin Smith
On Wed, Apr 03, 2024 at 11:53:09PM +0200, Patrice Dumas wrote: > To avoid that, you could change the special call to $document->tree > with an argument, like $document->tree(1) to be $document->tree(), as > the argument, which is only taken in into account in XS is such that an > handler only is

Re: Further reducing special case code for XS structuring

2024-04-04 Thread Gavin Smith
On Wed, Apr 03, 2024 at 11:53:09PM +0200, Patrice Dumas wrote: > On Wed, Apr 03, 2024 at 09:23:28PM +0100, Gavin Smith wrote: > > This does appear to make texi2any work with TEXINFO_XS_STRUCTURE=0, although > > there are various test failures that I haven't investigated properly > > It appears

Re: Further reducing special case code for XS structuring

2024-04-03 Thread Patrice Dumas
On Wed, Apr 03, 2024 at 09:23:28PM +0100, Gavin Smith wrote: > This does appear to make texi2any work with TEXINFO_XS_STRUCTURE=0, although > there are various test failures that I haven't investigated properly > It appears that the failures are to do with @item; e.g. for > "converters_tests.t

Re: Further reducing special case code for XS structuring

2024-04-03 Thread Patrice Dumas
On Wed, Apr 03, 2024 at 09:23:28PM +0100, Gavin Smith wrote: > We previously discussed the interface of the XS modules and trying to > improve their abstraction so that the same interface was used for both > XS and non-XS code. (Emails from 2024-02-23 "Better abstraction of > Texinfo::Document

Re: Further reducing special case code for XS structuring

2024-04-03 Thread Gavin Smith
On Wed, Apr 03, 2024 at 09:23:29PM +0100, Gavin Smith wrote: > We previously discussed the interface of the XS modules and trying to > improve their abstraction so that the same interface was used for both > XS and non-XS code. (Emails from 2024-02-23 "Better abstraction of > Texinfo::Document

Further reducing special case code for XS structuring

2024-04-03 Thread Gavin Smith
We previously discussed the interface of the XS modules and trying to improve their abstraction so that the same interface was used for both XS and non-XS code. (Emails from 2024-02-23 "Better abstraction of Texinfo::Document interface regardless of XS".) We made changes in this direction.