>>>>> 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/
