Re: 21.5.x crypt.el + MULE + encoding bug (and potential fix)

BAW> Anyway, through quite a bit of testing what appears to be BAW> happening is that \r's in the original encrypted text are BAW> getting converted to \n's when read from call-process. It's BAW> also possible that they will get converted when written back BAW> out to file. This happens even when the buffer's coding is BAW> 'binary, and it's obvious to see how this will corrupt the BAW> saved encrypted file. BAW> My fix for this is in crypt.el's crypt-write-file-hook BAW> function. I'm sorry I don't have a diff, but the fix is BAW> fairly simple. OTOH, I'm not sure it's the /right/ fix. In BAW> any event, in the let (see ;; BINDINGS) at about line 1689 BAW> which encloses the calls to crypt-encrypt-buffer and BAW> write-region, I've added these bindings: BAW> (coding-system-for-read 'binary) BAW> (coding-system-for-write 'binary) I don't use crypt, so I can't say for sure, but your theory is right and this is the theoretically correct fix. I'll fiddle with it a bit, but the main thing that would hold up a package release IMO is writing a test suite. It's a bit of a kludge, but I think what can be done is to add a file to the *core* test It appears that both are necessary. With this fix I can read and write encrypted files again! :) I believe I'm using the latest crypt.el from os-utils 1.37 (crypt.el says 2.83 at the top). Please let me know if you think a better fix is in order. I'll be happy to test anything to get this fixed in the next package release. Cheers, -Barry -- School of Systems and Information Engineering 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.