Tim Connors <tconnors(a)astro.swin.edu.au&gt; writes: If you mean why the hell does Gnus use ISO 2022-JP for 8-bit mail, all I can say is, "Welcome to the wonderful world of MULE"! :-)

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.

Hrvoje> Using iso-8859-1 as charset would make it viewable and Hrvoje> savable for the largest subset of users. If I were in Hrvoje> Lars's position, I'd use that and hope the world forgives Hrvoje> me for mislabeling 128-160 range. But that's not the problem. The problem is converting to a 7-bit representation. Quoted-Printable is unreliable (many MUAs implement it incorrectly), BASE64 unacceptable (it bumps your spamassassin rating by 2.0 IIRC ;-), 8bit is unreliable. So larsi is stuck with (*gag* *retch*) ISO-2022. Hrvoje> As long as we're (mis)labeling binary as text, we have to Hrvoje> resort to an approximation. So fix that. "Hey, Beavis! This buffer is full of non-characters in your locale. WTF??! Put it in an attachment where it belongs!" or however larsi would say that. Hrvoje> Doesn't message set the coding system to "escape-quoted", Hrvoje> at least under XEmacs/Mule? Yes. That's an inspired hack that ensures that drafts and autosaves are interchangable, it seems to me. -- 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.

Simon> This requires that the backtrace buffer was originally Simon> labeled as binary/noconv by XEmacs, but this seems to be I don't see why it requires that. It would make it convenient, yes, but in fact buffers cannot contain binary data, only characters. If it is possible to have an inversion between the characters in the buffer and the file on disk, then we call that a "binary coding system". However, any coding system that can represent character values corresponding to all bytes is satisfactory. The thing to remember is that changing the coding system does _nothing_ to buffer contents. It only changes the conversion on I/O. Simon> Isn't data recoded when it is copied between buffers? No. Never. All Mule data internally has the same internal coding system. This is not quite true for GNU Emacs. GNU Emacs _does_ do recoding (or at least it did in 20.x). That's why GNU Emacs had the recurrent "\201 corruption" bug, which never occurred in XEmacs (once Mule became even bistable :-). You'd get an "Ebola check" assertion first. Simon> If data is not recoded when it is copied between buffers, Simon> then I don't understand how things could work unless the Simon> data itself keep information about what coding system it is Simon> in, but IIRC that is not how MULE works. That's right. The Mule encoding itself, and any editing operations, don't know about coding systems; that's Emacs's job. What Mule does do is to keep the _charset_ of each character in the character in the buffer, then it finds an appropriate coding system for I/O operations. Simon> Are you talking about autodetection? Isn't it possible, Simon> instead, to add some code that says the backtrace buffers Simon> are binary/noconv? Not reliably. Because once the characters are copied, they lose that "tagging". What you could do is add code to the backtrace buffer to put it on a text property. Then you could kill it/copy it to the kill ring/copy it to a scratch buffer/edit out parts you don't want to see/ etc. The problem can mostly be avoided if message-mode provided a convenient "edit and attach buffer" command. Then you'd say C-c C-a *backtrace* RET <edit, schmedit> C-c C-c and it would be attached as application/x-raw-backtrace or somesuch. M-x mml-attach-buffer is a reasonable approximation. What's happening now is C-x B *backtrace* RET C-x h M-w C-x b RET C-y (or some approximation). However, if the author decides to edit (eg, interleave comments in the backtrace) you're probably hosed no matter what you do. The best you can do is what Gnus does. Data integrity must come first. Simon> Autodetecting should IMHO be avoided if possible, What must be autodetected to prevent data corruption can be reliably detected. Simon> and for backtraces we know (I believe) that the data must Simon> be preserved as is. ISO-2022-JP-2 does that. -- 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.

Tim> Why the hell does it do that?! Go to Athens, turn right, go 150km, stop at Delphi. There's a Support Desk there that handles questions like this. -- 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.