Re: MD5 comparison fails in package-get
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> wrote:
I'm not going to submit a patch yet because I simply do not
understand
what the heck is going on. There is _all_ kinds of evil lurking in
those functions. Not to mention confusing comments like "whatever
happened to i-f-c-literally?" (in package-get.el), which makes no
sense, as AFAIK it never went AWOL.
I'll bet that it is the file-coding insanity. I've been going
through file-coding hell trying to get crypt.el to work, and I'm coming
to the conclusion that the design of the coding system is to blame (it's
not a bug -- it's the design itself).
One basic issue is that, if you use the default coding "undecided"
and allow XEmacs to determine the coding system, you must know
beforehand if a file is binary or not (*if* you can't tell from the file
extension). The problem is that, for "undecided" binary files, XEmacs
often thinks binary files have a "Macintosh" line ending, which ends up
corrupting the file on reads. As a result, I've got a lovely kludge to
crypt.el where crypt reloads the file in binary mode if it detects that
the file was loaded in non-binary mode. Of course, this is extremely
user-hostile for large files.
[ I'm not sure if I should submit my crypt.el patches, as I'm wondering
if it's just better to drop-kick file coding and recompile XEmacs
without it. ]
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.