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

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonathan <at> jonreeve.com, 57531 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: bug#57531: 28.1; Character encoding missing for "eo"
Date: Tue, 04 Oct 2022 13:44:10 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Something like the below could be acceptable, if it solves the
> problem.
>
> diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el
> index 4137642..6866291 100644
> --- a/lisp/international/mule-cmds.el
> +++ b/lisp/international/mule-cmds.el
> @@ -2317,7 +2317,7 @@ locale-language-names
>      ;; en_IN -- fx.
>      ("en_IN" "English" utf-8) ; glibc uses utf-8 for English in India
>      ("en" "English" iso-8859-1) ; English
> -    ("eo" . "Esperanto") ; Esperanto
> +    ("eo" "Esperanto" locale-info) ; Esperanto

(etc).  This does not seem to fix the problem.

LANG=eo ./src/emacs -Q

still says

current-locale-environment
"eo_XX.ISO8859-3"

This does work (with or without the patch):

LANG=eo.UTF-8 ./src/emacs -Q
current-locale-environment
"eo.UTF-8"

Anyway, re-skimming this thread, I think we have these points:

1) The "eo" environment should be in utf-8 -- all the indications seem
to point to that, except some outdated Debian files that nobody else
uses but Emacs.

2) Using eo.UTF-8 is a work-around that works fine.

3) Changing what Emacs does here might be disruptive to people that are
used to Emacs defaulting to Latin-3 for the "eo" locale.

So the question is whether Emacs should start doing the right thing as
1), or worry more about 3).

I'm leaning more towards 1), but I don't have a strong opinion.

Previous Next

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