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

Coding cookie is part of the proposed patch.  (Un)fortunately `write-region'
does not add coding cookies to file, and i don't see any easy way how to
customize it.  If you want the -*- coding: bla-bla-bla -*- thing then insert it
yourself before calling `write-region'.  In other words -- duplicate
coding-system selection from `write-region' in your code.

Default coding system for abbrev file. As soon as you start talking about
convention on coding system a user appears that asks: "Hei! How can I change
the default codesys?  I dont like ur iso-bla-bla, I wanna utf-bla-bla!"

Come back to the proposed patch.  It includes user option
`abbrev-file-coding-system'.  XEmacs team might set it to whatever they want.
E.g. (if (featurep 'mule) 'iso-2022-8 'raw-text)
And users can change it to their taste.

But the patch also respects magic cookie in the input file.  It saves coding
system that was used to read abbrevs and uses when writes abbrevs back.

In order to learn coding system from abbrev file I had to steal code from
`load'.  Another duplication of coding-system selection logic.

So, if you want coding cookie and/or default coding system then you are
likely to duplicate some coding-related code.

If you don't want to duplicate code then use `file-coding-system-alist':
(when (find-coding-system 'windows-1251)
  (modify-coding-system-alist
   'file
   (regexp-quote (file-name-nondirectory abbrev-file-name))
   'windows-1251))

Nick.

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

  HN> "Stephen J. Turnbull" <[email protected]> writes:
  Hrvoje> Maybe abbrev-saving code should add a "-*-" coding cookie so the
  Hrvoje> coding system used is explicit?
  >>
  >> No.  Coding cookies guarantee corruption, unless the system automatically
  >> maintains them.

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

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

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

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