GNU bug report logs -
#4623
23.1.50; rmail changes encoding of characters on save
Previous Next
Full log
View this message in rfc822 format
The cure for this bug, viz.
*** rmail.el 6 Oct 2009 06:40:40 -0000 1.554
--- rmail.el 13 Oct 2009 01:17:20 -0000
***************
*** 4176,4181 ****
--- 4176,4182 ----
(defun rmail-write-region-annotate (start end)
(when (and (null start) (rmail-buffers-swapped-p))
(set-buffer rmail-view-buffer)
+ (set (make-local-variable 'coding-system-for-write) 'no-conversion)
(widen)
nil))
is IMO not much better than the disease: now C-x C-s _always_ leaves
the RMAIL buffer in no-conversion state, until you display a message,
e.g., with "M-n".
I think this happens because the above sets the encoding of
rmail-view-buffer, where we display the messages, to no-conversion.
I'm not sure how to solve this. What is needed is bind
coding-system-for-write to no-conversion just for the duration of
save-buffer or write-region that it calls eventually. But because we
use annotations to switch the buffer behind save-buffer's back,
there's no easy way of doing that.
Perhaps we should special-case RMAIL in save-buffer, or maybe do
something in buffer-swap-text.
Any ideas are welcome. If no better idea pops up very soon, I suggest
the following band-aid for Emacs 23.2:
. don't set coding-system-for-write in rmail-write-region-annotate
. bind C-x C-s in Rmail mode to a special command, like rmail-save,
which will bind coding-system-for-write to no-conversion
. wrap all instances of save-buffer in Rmail with a form that
let-binds coding-system-for-write to no-conversion
This will at least plumb the problem in 99% of use cases, I think.
This bug report was last modified 15 years and 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.