Re: [PATCH] Fix unwanted character conversion in pop3.el
intro: "HN" == Hrvoje Niksic <hniksic(a)xemacs.org> 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)