Re: [PATCH] Unicode Lisp reader escapes

[Oliver Scholz]

Richard Stallman <address@hidden> writes:

>     > Handa says that telling people "don't use utf-8" solves the problem.
>
>     That's NOT what I saied.  I said "use emacs-mule".  The
>     other coding systems are affected by
>     unify-8859-on-decoding-mode, and also by users setting of
>     standard-translation-table-for-decode.
>
> Ok, I stand corrected.
>
> However, people have pointed out that there are practical drawbacks
> to using emacs-mule, and that iso-2022 is more convenient.
> Let's see if we can arrange for iso-2022 to work properly.

The same here. decode_coding_iso2022 (which is also responsible for
some ISO 8859 encodings) refers to
Vstandard_translation_table_for_decode.

The practical drawbacks *I* mentioned are basically the same with ISO
2022-7bit. (Disclaimer: I don't really understand ISO 2022. I am not
even sure that this particular ISO standard specifies an encoding
(character set + transfer encoding) or rather a standard *for*
specifying encodings.) I see that ISO-2022-JP-2 is, thanks to Kenichi
Handa, a registered IANA encoding. (But that is probably not the same
as ISO 2022-7bit?) But that means only that you are not, strictly
speaking, violating a standard if you use it in mail or news. In
practise, however, I very much doubt that outside of Japan there are
any editors, mail clients or news clients other than Emacs that are
able to deal with it.

I don't know whether being "8 bit clean" is still an issue for
networking connections today. If it is, then ISO-2022-7bit might have
an advantage for files in a CVS repository. But that's pretty much the
only advantage in practise.


    Oliver
-- 
Oliver Scholz               27 Floréal an 214 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.