MF> Gnus under XEmacs 21.1 (patch 10) mangles the content of message with MF> charset=iso-8859-1 if they are sent as 8bit. For example a message MF> with German special characters might look like this in the MF> *Article* buffer: MF> This looks like iso-2022-jp, and indeed, the German special characters MF> can be made visible again, if one edits the charset in the MF> Content-Type: header from iso-8859-1 to iso-2022-jp. MF> This means that Gnus under XEmacs saves messages which contain 8-bit MF> German special characters as iso-2022-jp to disk. MF> The reason for that seems to be that the default value for MF> the variable 'buffer-file-coding-system' in XEmacs is iso-2022-jp" MF> ~$ xemacs -q -vanilla -eval "(message \"%s\" buffer-file-coding-system)" -batch MF> iso-2022-jp I think the intent is that buffer-file-coding-system is to default to iso-2022-8, as you suggest. (martin＠mule) ~ $ /usr/local/bin/xemacs -q -vanilla -eval "(message \"%s\" buffer-file-coding-system)" -batch iso-2022-8 (martin＠mule) ~ $ /usr/local/bin/xemacs -q -vanilla -version XEmacs 21.1 (patch 10) "Capitol Reef" [Lucid] (sparc-sun-solaris2.6, Mule) of Fri Jun 23 2000 on mule.m17n.org (martin＠mule) ~ $ mdev -q -vanilla -eval "(message \"%s\" buffer-file-coding-system)" -batch iso-2022-8 (martin＠mule) ~ $ mdev -q -vanilla -version XEmacs 21.2 (beta35) "Nike" [Lucid] (sparc-sun-solaris2.6, Mule) of Sun Jun 25 2000 on mule.m17n.org (martin＠mule) ~ $ As you can see, I don't get the same results as Mike does. More investigation is called for. Maybe those vanillas and batches aren't as effective as you think. Maybe there's an order dependency. MF> Gnus under GNU Emacs doesn't have this problem, in case of GNU Emacs MF> the default value of 'buffer-file-coding-system' is 'nil'. MF> Changing the default value in XEmacs of this variable to 'iso-2022-8' in MF> my .emacs cured the problem of mangled German messages in Gnus. MF> (when (string-match "XEmacs" emacs-version) MF> (set-default-buffer-file-coding-system 'iso-2022-8)) MF> Using 'escape-quoted' instead of 'iso-2022-8' seems to work as well. MF> The documentation of 'buffer-file-coding-system' mentions both as MF> 'reasonable' choices for the default value. MF> Then why is 'iso-2022-jp' the default value for MF> 'buffer-file-coding-system'? Does it have any negative side effects? MF> So far I couldn't discover any. Especially Japanese messages are still MF> displayed correctly. MF> Would it make sense to change the default value in XEmacs?