bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#57531: 28.1; Character encoding missing for "eo"


From: Lars Ingebrigtsen
Subject: bug#57531: 28.1; Character encoding missing for "eo"
Date: Tue, 04 Oct 2022 13:44:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@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.





reply via email to

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