>>>>> Markus Kuhn writes: > Another example for why using "nl_langinfo(CODESET)" or "locale > charmap" is far better than looking at the environment variables > with obscure rules:
On the contrary, as I tried to explain. In particular, I added Latin-9 support to Emacs long ago, and Latin-9 v. Latin-1 is just the sort of thing I was concerned about. Anyhow, I'm surprised any system has to change today and doubt it would be a good idea to change things under users' feet. Presumably they've already been using @euro or whatever. Emacs needs those `obscure rules', whether or not it can use nl_langinfo. If that returns something meaning ASCII, we probably want to look for a sensible language environment using the current code. > The mapping between locale names and encodings should really > be left to where it belongs, namely the C library. If it changes there, Emacs users could be messed up. Apart from the effect on using existing data, they may be surprised when creating new files and they'd probably find themselves using the wrong input method. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
