Re: XEmacs/Gnus problem with charset=iso-8859-1, 8-bit
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "MF" == Mike Fabian
<mfabian(a)suse.de> writes:
MF> The reason for that seems to be that the default value for the
MF> variable 'buffer-file-coding-system' in XEmacs is iso-2022-jp"
MF> ~$ xemacs -q -vanilla -eval "(message \"%s\"
MF> buffer-file-coding-system)" -batch iso-2022-jp
>>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes:
mb> I think the intent is that buffer-file-coding-system is to
mb> default to iso-2022-8, as you suggest.
This is with 21.2.34, not 21.1.10, but:
bash-2.04$ xemacs -q -vanilla -eval "(message \"%s\"
buffer-file-coding-system)" -batch
iso-2022-8
bash-2.04$ LANG=ja xemacs -q -vanilla -eval "(message \"%s\"
buffer-file-coding-system)" -batch
iso-2022-jp
I suspect Mike runs with his env LANG set to Japanese.
Thank you, I didn't think about that. You are right, I have LANG set
to 'ja_JP'. If I set LANG to 'C' or 'de_DE' the default of
buffer-file-coding-system becomes 'iso-2022-8', i.e. 21.1.10 behaves
the same as 21.2.34 in that respect.
But this is still a bug that runs deeper than just setting the
default
right.
If the default for 'buffer-file-coding-system' is set to 'iso-2022-8',
Gnus works correctly for at least 8-bit German and Japanese.
For other languages I can't tell.
It may be a problem with Gnus, I don't know.
Probably not only with Gnus. I had a similar problem about 1 year ago
with VM. Suddenly all German messages in my VM INBOX had been
converted to iso-2022-jp. I didn't find out why back than, but now I
think it was very likely the same problem with the value of
'buffer-file-coding-system'. With VM it is even worse, because it hits
your whole INBOX at once. That may be difficult to reverse, if your
INBOX contains many different languages. With Gnus and the nnml
backend (1 file per message), changing the default value of
'buffer-file-coding-system' affects only the messages coming in after
that.
But somebody somewhere should be saving that MIME information and
setting the b-f-c-s properly,
Maybe that would help for the nnml backend, but probably not for
nnfolder or VM.
or else the default should not be touched by the language
environment picked up from the LANG variable.
Maybe this is the best solution. Is there any reason why this
shouldn't work in all cases?
If the message is saved unchanged, exactly as it came in, Gnus and VM
should be able to use the MIME information to decode and display it
correctly. But if the encoding of the message body has been changed to
something else when XEmacs saved it, it is no wonder that Gnus
displays garbage.
--
Mike Fabian <mfabian(a)suse.de>