Aidan Kehoe <kehoea(a)parhasard.net> writes:
+(when (or vm-xemacs-mule-p
+ (and vm-fsfemacs-mule-p enable-multibyte-characters))
+
+ ;; Load any unicode support that's available. (If we're running on 21.5,
+ ;; utf-8 is predefined as a coding system, so there's no need to load
+ ;; Mule-UCS.)
+ (and (not (coding-system-p (find-coding-system 'utf-8)))
+ (locate-library "un-define")
+ (require 'un-define)
+ (require 'unicode))
I, for one, wouldn't want VM (or Gnus) to load the deprecated and
buggy "un-define" and "unicode" libraries. That kind of thing should
be left up to the user.
+ ;; If we can use latin-unity for sane treatment of the 8859-?
charsets
+ ;; under MULE, go for it.
+ (and (locate-library "latin-unity")
+ (require 'latin-unity))
The same goes for latin-unity IMHO.
+Under MULE, `vm-coding-system-priorities' is searched, in order,
for a
+coding system that will encode all the characters in the message. If none is
+found, `iso-2022-jp' is used, which will preserve information for all the
+character sets of which Emacs is aware--at the expense of being incompatible
+with the recipient's software, if that recipient is outside of East Asia."
Charming. Why do we ever fall back to "iso-2022-jp" for things we
send over the wire? Signalling an error would be kinder to the user
and her correspondents.