Re: [PATCH 21.5] Reading and writing abbrev file under MULE

Dropping -patches for the subthread because I haven't had a chance to
review the patch itself yet.  This is not a review, just general
discussion.

>>>>> "Hrvoje" == Hrvoje Niksic <[email protected]> writes:

    Hrvoje> [email protected] (Nickolay Pakoulin) writes:

    >> Default coding system does not help because abbreviations might
    >> use multiple charsets.  Fancy a user, who uses abbreviations
    >> for writing in Russian and French.  BUT the language
    >> environment is one of cyrillics, because the user works with
    >> Russian mostly.

    Hrvoje> Hmm.  Mule has the (mis)feature of saving buffers with
    Hrvoje> multiple charsets with ISO 2022 sequences, which it
    Hrvoje> usually recognizes when reading external files.  I haven't
    Hrvoje> tried mixing, for example, Latin 1 and Latin 2 abbrevs and
    Hrvoje> saving them to see what happens.

    Hrvoje> Maybe abbrev-saving code should add a "-*-" coding cookie
    Hrvoje> so the coding system used is explicit?

No.  Coding cookies guarantee corruption, unless the system
automatically maintains them.[1]  But a system that automatically
maintains coding cookies is nearly equivalent to ISO 2022, lacking
some features but containing all misfeatures ;-), unless the coding
cookie is _always_ -*- utf-8 -*-.

I think that since this is a file that is actually mostly internal to
Emacs, it should be saved in iso-2022-jp[2] or ctext by default, with an
option to save in UTF-8.

The exception is an abbrev file written by non-Mule Emacsen.  These
should have coding cookies unless they're ASCII.

    >> May be the hint with `file-coding-system-alist' should be added
    >> to the documentation.

    Hrvoje> I'm not sure what file-coding-system-alist does, but I'm
    Hrvoje> sure glad it helped you!  :-)

`file-coding-system-alist' maps file names to coding systems in the
same way as `auto-mode-alist' maps file names to major modes.  Of
course the difference is that the latter doesn't have potential for
corrupting data in most cases, it's just inconvenient if you get the
mode wrong.

Footnotes: 
[1]  Latin-unity contains some code for checking coding cookies, but
the Mule coding system namespace is so bollixed that it's probably
more trouble than it's worth.

[2]  ISO-2022-JP rather than ISO-2022-7 because the -JP version treats
all charsets symmetrically except for ASCII, and the special treatment
of ASCII is limited to the fact that if a stream does not start with
an escape sequence, the following characters are assumed to be ASCII.

The -7 version is underspecified and allows arbitrary use of the
features of ISO 2022.

ctext has the advantage that most of the time ISO 8859 coding systems
use _one_ escape sequence to designate the GR (8-bit-set) character
set for the rest of the file, and therefore looks almost natural to
the eye.  It would be possible to create a version of ctext that sets
the GR charset immediately, in which case the escape sequence could be
explained as "magic".  Note that this is basically how a coding cookie
works, except that the coding cookie is human-readable and -maintained
and easily corrupted or neglected by the human maintainer.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software