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

Well, you are right, Hrvoje.  No need in the patch :)

The `file-coding-system-alist' should be enough for most cases.  I just forgot
about the feature :)

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.

Then he/she need a multibyte coding system to store abbreviations because
single byte cyrillics coding system (e.g. koi8-r) will corrupt chars from
Latin1.  To see what will happen, try the following code:
(encode-coding-string (string (int-to-char 225)) 'koi8-r)

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

Nick.

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

  HN> [email protected] (Nickolay Pakoulin) writes:
  >> Current implementation of abbrev.el does not care about coding systems for
  >> reading and writing abbreviations.

  HN> Should it?  I mean, won't it simply use the default coding system of your
  HN> language environment?  That should also be the correct behavior, unless
  HN> I'm missing something.

  HN> It would be nice if the system at least tried to function so that random
  HN> pieces of code (such as abbrev-file loading and saving) didn't have to be
  HN> aware of coding systems, at least not explicitly.

  >> Under Mule, using non-ascii (e.g. russian) characters in abbreviations
  >> leads to incorrect behavior.  Write/read cycle corrupts such
  >> abbreviations.

  HN> How does the corruption occur?