> From: Gavin Smith <[email protected]> > Date: Tue, 10 Oct 2023 20:24:47 +0100 > Cc: [email protected], [email protected] > > On Tue, Oct 10, 2023 at 02:55:09PM +0300, Eli Zaretskii wrote: > > > If this simple stub is preferable to the Gnulib implementation for > > > MS-Windows, (e.g. it makes the tests pass) we could re-add it again. > > > > We can do that, but I think we should first explore a better > > alternative: use UTF-8 functions everywhere, without relying on the > > locale-aware functions of libc, such as wcwidth. For example, instead > > of wcwidth, we could use uc_width. > > Changing away from using wcwidth at this stage is a more significant > change to be making. I want to fix this issue in an easy and simple way. > As far as I am aware these tests passed on MS-Windows with previous > releases of Texinfo, so doing what we did before seems the simplest fix > to me.
Then we need to understand why the tests are now failing when they succeeded previously. > I'm not sure of the easiest way to put in a replacement for wcwidth > given that the wcwidth module is in use. I tried the stub implementation > as before with a different name, but this led to test failures, so may > not be enough. It's possible there have also been changes in the tests. > Do you know the last released version of Texinfo that passed the test > suite successfully? Texinfo 7.0.3 succeeded to run the tests. > I wonder if it is commit b9347e3db9d0 that is responsible (2022-11-11, > Patrice Dumas), or other changes to tp/tests/coverage_macro.texi that > change what is occurring in the line. I doubt that, since the previous versions already included, for example, the dotless j letter, which is one of those which cause trouble. > As I said before, one short-term fix I would be happy with is to split > the content up so there are shorter lines. Given that the purpose of > these tests is not to test line-breaking in itself, and that this is > a fragile part of texi2any's output, if line breaking is to be tested > this should be part of a specialised test. Any difference in the > line breaking for the coverage_macro.texi tests leads to a mass of > differences which are hard to interpret. We could put any problematic > characters on lines of their own, e.g. This would be fine by me, if filling is not the issue being tested there.
