Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Kenichi Handa <address@hidden> writes:

> Other application usually don't use such coding systems but
> use iso-2022-jp, iso-2022-kr, etc.  As charsets supported by
> each of them doesn't overlap (thus not unified), reading and
> writing by Emacs-unicode has no problem.

But there will be a problem if you rely on coding system
auto-detection.  For instance, if you write out a buffer showing the
jisx0208 charset as iso-2022-jp, Emacs 21 will auto-detect that
encoding when you visit the file.  However, Emacs 22 auto-detects it
as iso-2022-7bit -- I don't know if this is a bug -- and if you then
write it out, you'll get at least latin-iso8859-1 and chinese-gb2312
in the mix.

I was particularly warning about iso-2022-7bit, i.e. many of the Emacs
21 files in lisp/{language,international}, and ChangeLogs (which rms
already complained about) since this is going to developers.

[For the benefit of others:  Emacs 22 doesn't necessarily unify
characters from CJK sets, in particular -- it's done explicitly in the
Mule configuration, and can now be undone.  However, as things stand,
for example, you get a mixture of single- and double-width characters
used for non-Japanese parts of japanese-jisx0208, and Chinese used for
some of the Japanese, since a unification table for it is installed.
Hence my remarks concerning lack of complete unification qua bug.]