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

"Stephen J. Turnbull" <[email protected]> writes:

>     Hrvoje> Maybe abbrev-saving code should add a "-*-" coding
>     Hrvoje> cookie so the coding system used is explicit?
>
> No.  Coding cookies guarantee corruption, unless the system
> automatically maintains them.

That's pretty much what I was proposing.  If the coding cookie is
added automatically when saving (the abbrev file) and respected when
loading it, then it's "automatically maintained" in my book.

> [1] But a system that automatically maintains coding cookies is
> nearly equivalent to ISO 2022

Almost.  The problem cookies can solve is corruption when the user
switches environments.  For example: I work in a Latin 2 environment
and use only Latin 2 characters in cookies.  When the abbrev file is
saved, no ISO 2022 escapes will be used.  But I'd like the abbrev file
to be interpreted correctly even if I happen to be in a different
environment -- hence the coding cookie.

A similar effect could be achieved by forcing UTF-8 or ISO 2022 for
saving the abbrev file.  But I prefer the cookie approach, as it
allows even a non-Mule XEmacs to edit the resulting cookies (at least
for single-byte charsets).  And XEmacs can still switch to ISO 2022
(or UTF-8) when it's really necessary, such as when more than one
charset is present in the file.