bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Texinfo 7.0.93 pretest available


From: Gavin Smith
Subject: Re: Texinfo 7.0.93 pretest available
Date: Tue, 10 Oct 2023 20:24:47 +0100

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.

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?

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.

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.

diff --git a/tp/tests/coverage_macro.texi b/tp/tests/coverage_macro.texi
index 4c3f7408af..d4437fdac3 100644
--- a/tp/tests/coverage_macro.texi
+++ b/tp/tests/coverage_macro.texi
@@ -29,8 +29,11 @@
 @@`i @`i (ì)
 @@'@{e@} @'{e} (é)
 @@'@{@@dotless@{i@}@} @'{@dotless{i}} (í)
+
 @@dotless@{i@} @dotless{i} (ı)
+
 @@dotless@{j@} @dotless{j} (ȷ)
+
 @code{@@H@{a@}} @H{a}
 @code{@@dotaccent@{a@}} @dotaccent{a} (ȧ)
 @code{@@ringaccent@{a@}} @ringaccent{a} (å)


> Is it feasible to use UTF-8 in texi2any disregarding the locale, and
> use libunistring or something similar for the few functions we need in
> the extensions that are required to deal with non-ASCII characters?
> If we can do that, it will work on all systems, including Windows.
> (This is basically what Emacs does, but it does that on a much greater
> scale, which is unnecessary in texi2any.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]