[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs and UTF-8 locale
>>>>> Markus Kuhn writes:
> There are UTF-8 locales in use (e.g., vi_VI), which do NOT have
> UTF-8 in their name,
That looks like a bad example since, at least in glibc 2.2.4, the
locale is listed as `vi_VN.UTF-8'. That's fortunate, since Emacs uses
VISCII for the unqualified Vietnamese language environment.
(Similarly for Devanagari.) I documented other cases from glibc in
the code. Apparently they aren't all consistent with the source that
eggert originally used.
> therefore the direct test of the locale environment
> variables is just a less reliable fallback option.
> It is my understanding that elisp currently has no direct access to
> the output of the API function nl_langinfo(CODESET), and I hope
> this can be fixed.
I've implemented it, but it's not installed, partly _because_ people
may not end up with the coding they expect. I haven't yet tried to
check compatibility properly.
> Fortunately, there exists only one single standard string that
> nl_langinfo(CODESET) returns in a UTF-8 locale, and that is
> "UTF-8". (For ISO 8859-1, both "ISO-8859-1" and "ISO8859-1" are
> used by different manufacturers.)
Emacs already deals with that sort of issue and DTRT with the
environment variables, including matching something more general than
`UTF-8'. Please see the code in mule-cmds.el.
> if (strstr(s, "UTF-8"))
> utf8_mode = 1;
Testing solely for utf-8 isn't useful.
--
$ locale -c charmap
LC_CTYPE
ISO-8859-1
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/