Re: [SmokeTest Failure] 21.5-b11-nomule, tramp-1.13

Kai> "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Kai> I beg to disagree. They are necessary for informing the Kai> system about the charset used in a file. (Unless all of the Kai> files in a system are of the same encoding, which is not Kai> feasible in multi-user systems.) They are not necessary; if they were, they'd be required, and Emacs would refuse to edit a file that didn't have one, and dump core if it were incorrect. Kai> MIME uses coding cookies (in the form of charset attributes Kai> in the content-type header), HTML uses them, XML uses then Kai> (in the <?xml?> processing instruction), and I'm sure I could Kai> find other examples. But those are not cookies! Those are specific unambiguous syntax, and they are required by the standard's semantic specifications if the file is not in ASCII. Cookies (as used in Emacs, and now, to my great disgust, in Python) are random optional heuristics that are not part of the actual syntax. I'm willing to bet that a string of octets that looks like "coding: iso-8859-1"---note that that is probably legal Unicode, lowercase letters wold be the high byte of a Unicode character that falls in the Unihan block---will trigger the cookie recognizer in a file that is otherwise UTF-16, for example. Programmers regularly fail to update them when the coding system changes or copy them incorrectly from one file to the next, and no system (except for my Latin-unity) that I know of will warn the user if a cookie is incorrect. (Actually, I think python may refuse to run.) Kai> For me, it's convenient to store *.el files in Latin-1 or Kai> Latin-9 encoding, because that enables me to use grep on Kai> them, just like I do with other files. Kai> Is there any chance that XEmacs will grok *.el files in other Kai> encodings, or do I just have to bite the bullet and convert Kai> them to iso-2022-7bit? XEmacs does grok .el files in other encodings in the stable branch, doesn't it? As for 21.5, I'll take a look when I get back from Montreal, around 6/10. However, for now the right answer is "don't build Tramp (or other packages) in public with 21.5 unless your name is Mats Lidell". 21.5 shares very few lines of code with 21.4 in the coding system stuff; breakage should be expected. -- 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.