intro: "HN" == Hrvoje Niksic <hniksic(a)xemacs.org&gt; writes: HN> To my dismay, I noticed the dreaded ^[-A and ^[-B markers in Jamie HN> Zawinski's recent message that contained literal Latin 1 characters. HN> Since Jamie does not appear to use a Mule-based mail reader, I suspected HN> the corruption happened somewhere on my part. HN> Sure enough, when I send myself a mail with embedded 8-bit characters, it HN> is sent correctly, but gets corrupted when retrieved with XEmacs's HN> `pop3.el'. pop3's code does half of the job by using `binary' coding for HN> reading and writing to the network -- but it fails to do the same when HN> appending the data to the crashbox. Since my default coding system is HN> ISO 8859-2, Mule helpfully decided to adorn the Latin 1 characters with HN> ISO 2022 markup that Gnus doesn't know about or need. HN> I'm not sure how this kind of thing didn't get noticed before: I'm HN> beginning to wonder if I'm the only person on earth attempting to use HN> XEmacs/Mule with Latin 2 for anything more than casual editing. HN> Ironically, the `pop3.el' that ships with Gnus already contains the fix, HN> even though it's likely specific to XEmacs/Mule. Anyway, here is the HN> patch: This a hack from my init file, about 1 year old :) Happened to me when I moved to MULE Windows build and found russian postings heavily augmented. Once upon a time it became useless (gnus 5.8, I think), but had to use it again on gnus 5.10 Nick. ;;; POP3 ;; Evil hack for normal pop3 retrieval ;; Once pop3 buffer had encoding other than RAW. That made problems. (defvar pop3-crashbuf-name " *pop3-retr*") (defvar pop3-crashbuf-coding-system (when (featurep 'mule) (get-coding-system 'raw-text))) (defun pop3-write-region-pre-hook (start end filename append visit lockname coding-system) (when (featurep 'mule) (and (string= (buffer-name) pop3-crashbuf-name) pop3-crashbuf-coding-system))) (add-hook 'write-region-pre-hook 'pop3-write-region-pre-hook)

intro: "HN" == Hrvoje Niksic <hniksic(a)xemacs.org&gt; writes: HN> npak(a)ispras.ru (Nickolay Pakoulin) writes: HN> It depends on which `pop3.el' you use, which is largely a function of HN> which one is first in your `load-path'. Something like `(locate-library HN> "pop3")' will help you determine it. HN> If you are in fact using mail-lib's pop3, my patch should remove the need HN> for your hack. If not, I'd like to know what the problem is. A HN> corruption for you might mean a potential corruption for me. We Slavic HN> people are in it together. :-) pop3.el is from mail-lib. Your patch really fixed the problem. Shame on me :) I made similar patch more than a year ago, but either forgot to send it to xemacs-patches, or it died there. Then I installed new version of packages and the changes were lost but instead of fixing pop3.el I came down to the hack that I posted :)) Anyway, thank you, Hrvoje, for the patch! Nick.