Re: Microsoft declared "attractive nuisance"; expect list delays

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, and so is omitting the charset parameter (which implies US-ASCII). UTF-8 looks best to me, except that no stable Emacsen supports it out of the box. But all Mule-capable Emacsen (going back to 18.59) support ISO-2022-JP-2 (after all, Handa-san wrote that RFC!) as a universal coding system. What would you do? Simon> Perhaps the backtrace buffer is in the default coding Simon> system, which happen to result in 2022-JP for some users? 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. Ie, Gnus. The coding system of the source buffer is irrelevant. No matter how you slice it, you get "Gnus done it." Simon> Perhaps XEmacs should encode backtraces as binary instead Simon> of the default text coding system? For me, backtrace Simon> buffers are ISO8, which I think is equally incorrect. It's essentially impossible to recognize both noconv and iso8, each will shadow the other. Having iso8 shadowed makes no sense for most applications, so it works out that the only way to get the binary indicator under normal conditions is to explicitly set the coding system to binary. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.