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:28:52 +0100

On Tue, Oct 10, 2023 at 10:03:46PM +0300, Eli Zaretskii wrote:
> > From: Gavin Smith <gavinsmith0123@gmail.com>
> > Date: Tue, 10 Oct 2023 18:09:15 +0100
> > Cc: Eli Zaretskii <eliz@gnu.org>, bug-texinfo@gnu.org
> > 
> > On Mon, Oct 09, 2023 at 11:32:49PM +0200, Bruno Haible wrote:
> > > Gavin Smith wrote:
> > > > It is supposed to attempt to force the locale to a UTF-8 locale.  You
> > > > can see the code in xspara_init that attempts to change the locale.  
> > > > There
> > > > is also a comment before xspara_add_text:
> > > > 
> > > >   "This function relies on there being a UTF-8 locale in LC_CTYPE for
> > > >   mbrtowc to work correctly."
> > > 
> > > That's an inherently unportable thing. You can't just force an UTF-8
> > > locale if the system does not have it.
> > 
> > The module shouldn't load if it can't switch to a UTF-8 locale.  xspara_init
> > returns a different value if these attempts fail leading the code loading
> > the module (in Texinfo::XSLoader) to fall back to the pure Perl version.
> 
> If the inability to load the UTF-8 locale means the modules cannot be
> loaded, I consider that a serious problem, because Perl implementation
> is slower.  We need every possible way of speeding up texi2any,
> because the speed regression since Texinfo moved to the Perl
> implementation is significant, so much so that some refuse to upgrade
> from Texinfo 4.13 (and thus hold back usage of new Texinfo features in
> the various GNU manuals).  We cannot afford losing speedups due to
> such issues, especially since they are solvable using readily
> available libraries.

It worked before as far as I knew in previous releases (you wrote some
of the code for it) and I don't think anything has fundamentally changed.
There shouldn't be any loss of functionality on what has existed in
previous releases.  I was not proposing turning off the XS modules in
case a UTF-8 locale wasn't found.  I appreciate that MinGW support is
a special case and things can work differently there.

> > It would be good to get away from the attempts to switch to a UTF-8 locale
> > but I doubt it is urgent to do before the release, as the current approach,
> > however flawed, has been in place and worked fairly well for a long time
> > (since the XS paragraph module was written).  At the time it seemed to be
> > the only way to get the information from wcwidth.
> 
> Then what do you propose to do about this in the MinGW port of Texinfo
> 7.1?  And why is it urgent to release Texinfo 7.1 without fixing this
> issue?

See my other message.



reply via email to

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