XEmacs/Gnus problem with charset=iso-8859-1, 8-bit

Gnus under XEmacs 21.1 (patch 10) mangles the content of message with charset=iso-8859-1 if they are sent as 8bit. For example a message with German special characters might look like this in the *Article* buffer: This looks like iso-2022-jp, and indeed, the German special characters can be made visible again, if one edits the charset in the Content-Type: header from iso-8859-1 to iso-2022-jp. This means that Gnus under XEmacs saves messages which contain 8-bit German special characters as iso-2022-jp to disk. The reason for that seems to be that the default value for the variable 'buffer-file-coding-system' in XEmacs is iso-2022-jp" ~$ xemacs -q -vanilla -eval "(message \"%s\" buffer-file-coding-system)" -batch iso-2022-jp Gnus under GNU Emacs doesn't have this problem, in case of GNU Emacs the default value of 'buffer-file-coding-system' is 'nil'. Changing the default value in XEmacs of this variable to 'iso-2022-8' in my .emacs cured the problem of mangled German messages in Gnus. (when (string-match "XEmacs" emacs-version) (set-default-buffer-file-coding-system 'iso-2022-8)) Using 'escape-quoted' instead of 'iso-2022-8' seems to work as well. The documentation of 'buffer-file-coding-system' mentions both as 'reasonable' choices for the default value. Then why is 'iso-2022-jp' the default value for 'buffer-file-coding-system'? Does it have any negative side effects? So far I couldn't discover any. Especially Japanese messages are still displayed correctly. Would it make sense to change the default value in XEmacs? -- Mike Fabian <mfabian(a)suse.de&gt;