On Sat, Oct 05, 2024 at 02:52:55PM +0200, Patrice Dumas wrote: > On Sat, Oct 05, 2024 at 11:00:05AM +0100, Gavin Smith wrote: > > I'd also like to know how many more of these commits are coming. > > I still have some conflict/rebasing/cherry picking anomalies that may > require one or two small commits. > > After that, there are 4 commits that are still pending, corresponding to > an implementation of INFO_MATH_IMAGES in Info. They could be left for > the next release if you prefer.
As there are already huge changes since 7.1 it would be better to leave them, if it does not cause too much trouble with rebasing. > > From this point on, I have had much less understanding of the code > > in texi2any. Correspondingly, my ability and interest to fix issues > > in texi2any has gone down. I don't know if there was any alternative, > > though. > > The commits of this time are mainly (I have probably missed some) > * improvement of C parser performance, mainly memory, but also speed, > including some new tests for special cases determined when doing that Yes, texi2any really seems much snappier these days. It's great you've been able to reduce time and memory usage. > * convert def line category not in code > * @*ref formatting different in Plaintext than in Info > * translation of Perl to C for speed increase of conversion to HTML. > This includes adding CSV files to describe output used to generate > both C and Perl code. > * setup separate po directories for gnulib strings > * use C strings in po files. > * More translation of Perl to C for speed increase of conversion to HTML. > * Add a demonstration program in C that converts to HTML > * Fix compiler warning, refactor C code to avoid having all the > conversion in only one file > * Add C++ code to have an hashmap when Perl is not used > * update to libintl-perl-1.33 > * simplify passing arguments to converters from texi2any.pl and XS > version set to main version Thanks for writing this. > > I thought that having some more of Patrice's private changes on master > > might prevent a recurral of this situation with a huge number of changes > > being made after a release. > > Also for me it had become very time consuming to rebase and cherry pick > after master got important changes lately. I think that it is also > better to have all this code in the release, as the user visible changes > are few (and could easily be reverted as they are more or less > independent of th ebig changes going). Yes, you have to keep it manageable by not diverging too much. Otherwise you could get to the point where your work is lost because you are not able to reconcile it with the master branch.
