Re: MD5 comparison fails in package-get

Darryl> I'll bet that it is the file-coding insanity. I've Darryl> been going through file-coding hell trying to get crypt.el Darryl> to work, and I'm coming to the conclusion that the design Darryl> of the coding system is to blame (it's not a bug -- it's Darryl> the design itself). Well, you can take that position if you like. It's not unreasonable. But ambiguous coding systems cannot be avoided in multilingual applications for the foreseeable future; there are just too many different encodings competing for 0x80-0xFF :-) Darryl> One basic issue is that, if you use the default Darryl> coding "undecided" and allow XEmacs to determine the Why is this happening? The point is that if users are loading in files, editing them as text, and then doing some crypt operation on them, you have to write them out encoded before crypting them anyway. (This can be short-circuited by using function like `encode-coding-region' on the buffer. But you can't do this if the data has been "corrupted", the encoding is not necessarily reversible. No-op sequences of charset designation escape sequences will simply disappear in the buffer representation, for example.) If the application doesn't permit you to forbid that, then users are going to make mistakes, either by themselves (forgetting the coding system argument) or by proxy (defaulting to 'undecided). Darryl> coding system, you must know beforehand if a file is Darryl> binary or not [...] a lovely kludge to crypt.el where Darryl> crypt reloads the file in binary mode if it detects that Darryl> the file was loaded in non-binary mode. Of course, this Darryl> is extremely user-hostile for large files. Yup. Your point is well taken; your alternative might be? As you point out, the buffer data has already been corrupted. What you really need to do is keep the user from reading in non-Unix-ASCII text as text in the first place. A crude attempt: Darryl> [ I'm not sure if I should submit my crypt.el patches, as Darryl> I'm wondering if it's just better to drop-kick file coding Darryl> and recompile XEmacs without it. ] This is not an alternative for Japanese-, Chinese-, and Korean- speaking users. Obviously, it should be possible to make XEmacs's default encoding 'binary. A command line switch might be satisfactory for non-Asian users. However, Asians would still like to use crypt.el I'm sure, and that default would not be satisfactory for them. We still need something like your patches. I hope you'll submit them. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."