Re: Microsoft declared "attractive nuisance"; expect list delays
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> Well, I don't think Gnus would tag it as ISO 2022-JP for no
Simon> reason.
Heh. Ask larsi. I think the reason probably was "Content-Type:
application/octet-stream" would drive users into a killing rage. What
alternative does he have? UTF-8 and ISO-8859-X are just as wrong,
Using iso-8859-1 as charset would make it viewable and savable for the
largest subset of users. If I were in Lars's position, I'd use that
and hope the world forgives me for mislabeling 128-160 range.
That's how XEmacs/Mule sees charactres in 0-255 range anyway (with the
exception of 128-160, which are conceptually control-1). FSF has
unibyte buffers, which are a good solution as long as you don't need
to mix multibyte and unibyte.
I'm no fan of prolonging the "binary == Latin 1" myth, but that
particular myth is at least shared with the rest of the world, unlike
"binary == Japanese". As long as we're (mis)labeling binary as text,
we have to resort to an approximation.
Mule doesn't work that way. What matters is the coding system of
the
message composition buffer, which is (normally, for Gnus users) under
the control of message-mode.
Doesn't message set the coding system to "escape-quoted", at least
under XEmacs/Mule?