GNU bug report logs - #57531
28.1; Character encoding missing for "eo"

Previous Next

Full log

Message #61 received at 57531 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: jonathan <at> jonreeve.com, 57531 <at> debbugs.gnu.org
Subject: Re: bug#57531: 28.1; Character encoding missing for "eo"
Date: Sun, 04 Sep 2022 10:46:29 +0300

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: jonathan <at> jonreeve.com,  57531 <at> debbugs.gnu.org
> Date: Sun, 04 Sep 2022 09:34:44 +0200
> 
> On Sep 04 2022, Eli Zaretskii wrote:
> 
> >> From: Andreas Schwab <schwab <at> linux-m68k.org>
> >> Cc: Jonathan Reeve <jonathan <at> jonreeve.com>,  57531 <at> debbugs.gnu.org
> >> Date: Sun, 04 Sep 2022 09:03:00 +0200
> >> 
> >> On Sep 04 2022, Eli Zaretskii wrote:
> >> 
> >> > If you can show me some authoritative source of information about this
> >> > locale
> >> 
> >> (locale-info 'codeset)
> >
> > If you mean that set-locale-environment should use that, please say
> > that explicitly.  And then feel free to suggest a patch that does TRT
> > with all the convoluted logic and preferences there, so that we don't
> > disrupt the setup it took us decades to come up to, for the benefit of
> > a single obscure locale.
> 
> It's not for a single obscure locale, it's for all of them.

Does that mean you do suggest that set-locale-environment calls
locale-info?  Or do you suggest something different?

Anyway, for all the other locales, the current code already works, and
works well.  So we will be risking breakage while fixing one locale
that on one particular OS works less well.

But like I said: feel free to submit a patch that doesn't potentially
destroy everything we have in that setup.  If the patch is safe
enough, I see no reason not to accept it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.