Re: Texinfo 7.0.93 pretest available

[Gavin Smith]

On Wed, Oct 11, 2023 at 02:59:06PM +0300, Eli Zaretskii wrote:
> > From: Gavin Smith <gavinsmith0123@gmail.com>
> > Date: Tue, 10 Oct 2023 20:24:47 +0100
> > Cc: bruno@clisp.org, bug-texinfo@gnu.org
> > 
> > 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.

> > Do you know the last released version of Texinfo that passed the test
> > suite successfully?

> Texinfo 7.0.3 succeeded to run the tests.

Texinfo 7.0.3 also used the gnulib wcwidth module.  There is a slight chance
it is due to changes in gnulib but the wcwidth.c file from gnulib is identical
apart from the copyright year.

> > 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.

In one of the output files in Texinfo 7.0.3, one part of the output is
(in tp/tests/layout/res_parser/formatting_info/formatting.info)

   @"u ü @"{U} Ü @~n ñ @^a â @'e é @=o ō @'i ì @'{e} é @'{@dotless{i}} í
@dotless{i} ı @dotless{j} ȷ @'{@=E} Ḕ @l{} ł @,{@'C} Ḉ @,c ç @,c@"u çü

In the current development version, the output for the same paragraph is (now
in tp/tests/coverage/res_parser/formatting_info/formatting.info)

   @"u ü (ü) @"{U} Ü (Ü) @~n ñ (ñ) @^a â (â) @'e é (é) @=o ō (ō) @'i ì
(ì) @'{e} é (é) @'{@dotless{i}} í (í) @dotless{i} ı (ı) @dotless{j} ȷ
(ȷ) ‘@H{a}’ a̋ ‘@dotaccent{a}’ ȧ (ȧ) ‘@ringaccent{a}’ å (å)
‘@tieaccent{a}’ a͡ ‘@u{a}’ ă (ă) ‘@ubaraccent{a}’ a̲ ‘@udotaccent{a}’ ạ
(ạ) ‘@v{a}’ ǎ (ǎ) @,c ç (ç) ‘@,{c}’ ç (ç) ‘@ogonek{a}’ ą (ą)


which is much longer and more likely to have problems.  As you can see
the dotless j character was in the last line of the paragraph originally
and so wouldn't affect the line breaking. 

Commit f8a820fd (2022-11-11) was also responsible for creating longer lines.
Regardless of the exact point the tests would have broken or which characters
it broke for, using shorter paragraphs in this section (i.e. of one line)
is the obvious fix to try.

(Admittedly, the line breaking would still be inconsistent for MinGW,
but this wouldn't be picked up by the test suite.  It would only matter
in languages other than English if they use these characters a lot.)

I will send you a diff to try to see if it lets the tests pass, or if
we need to make any further changes.