>>>>> Kenichi Handa writes: > It seems that it doesn't have a major problem,
I hope not, because I've basically used your customization hooks or similar ones and done the sort of things you'd talked about at some time! > but I found one problem related to handling unibyte case. I didn't expect it to do anything sensible with unibyte, but if there's an easy to improve it, that would be fine. > 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. Yes. I'm not sure that should change, but the relevant primitives could now use `translation-table-for-input'. It wasn't the sort of thing I could control in user-level customization anyway, without kludging it with a post-command hook. > 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. What would be correct? Is general Unicode text any different to, say, JISX-based Japanese in that respect? -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
