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

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.