language-environment and md5sum of packages

Yoshiaki> I noticed that after I did (set-language-environment Yoshiaki> 'japanese), package-get always failed due to md5sum Yoshiaki> mismatch. After I reset the language environment to Yoshiaki> English or ASCII, everything goes well. Yoshiaki> For example, Yoshiaki> (with-temp-buffer Yoshiaki> (insert-file-contents-internal Yoshiaki> "/var/tmp/xemacs-devel-1.19-pkg.tar.gz") Yoshiaki> (md5 (current-buffer))) Without more context, this needs to be (md5 (current-buffer) nil nil 'binary) ; Tower of Babel hack I don't know for sure that the code above will work in the context of package-get, but probably it will (I am assuming package-get would never do an md5 on anything but the raw file data of a package). The problem is that in the Asian language environments Mule assumes that non-ASCII files are human readable text in some natural language encoding, in English it assumes they're binary or iso-8859, which is about the same thing in the current implementation. md5 goes off and asks Mule to guess the file-coding system for the file on disk and gets it wrong. Apparently `insert-file-contents-internal' does not update the buffer's idea of file-coding-system (if it updated it to binary, md5 would get the sums right), but I haven't traced it fully. I don't know what, if anything, the overall fix should be (I don't know if insert-file-contents-internal should be mucking with buffer meta-data, but I think not). Yoshiaki> I guess 'insert-file-contents-internal' does code Yoshiaki> conversion, but I didn't confirmed so far. No, according to the docs: ------------------------------------------------------------------------ `insert-file-contents-internal' is a built-in function (insert-file-contents-internal FILENAME &optional VISIT BEG END REPLACE CODESYS USED-CODESYS) Documentation: Insert contents of file FILENAME after point; no coding-system frobbing. This function is identical to `insert-file-contents' except for the handling of the CODESYS and USED-CODESYS arguments under XEmacs/Mule. (When Mule support is not present, both functions are identical and ignore the CODESYS and USED-CODESYS arguments.) If support for Mule exists in this Emacs, the file is decoded according to CODESYS; if omitted, no conversion happens. If USED-CODESYS is non-nil, it should be a symbol, and the actual coding system that was used for the decoding is stored into it. It will in general be different from CODESYS if CODESYS specifies automatic encoding detection or end-of-line detection. Currently BEG and END refer to byte positions (as opposed to character positions), even in Mule. (Fixing this is very difficult.) ------------------------------------------------------------------------ This is what reading the function seems indicate it should be doing under 21.0 "Poitou". More or less it "converts" the file to Qbinary. I haven't traced what get-coding-system and find-coding-system are doing carefully, but it seems they should be returning Qbinary. So `insert-file-contents-internal' is unlikely to be doing any conversion. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."