Dave Love <[EMAIL PROTECTED]> writes: >>>>>> Eli Zaretskii writes: >> I think the decision to leave it disabled in v21.1 was correct, >> since the application code, written by Dave, to make that support >> reasonably complete was only recently added to the CVS tree.
> I don't know what that means. The trivial utf-8 language environment > I offered could easily have been installed to fix the bug of not > honouring the locale. The only way I've significantly improved the > support of utf-8 encoding recently is by additions to characters.el > and providing experimental level 2 support for some scripts. I don't > think that's too important. I've just read the code added by Dave (sorry for not doing that earliear). It seems that it doesn't have a major problem, but I found one problem related to handling unibyte case. If unify-8859-on-decoding-mode is on, for instance, in latin-2 lang. env., 8859-2 characters files are decoded into latin-iso8859-1 and mule-unicode-0100-24ff. But, C-q XXX still inserts latin-iso8859-2 characters. And, when we paste mule-unicode-0100-24ff characters into unibyte buffer, or paste unibyte string into a multibyte buffer, they are not correctly converted. --- Ken'ichi HANDA [EMAIL PROTECTED] -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
