bug#4623: 23.1.50; rmail changes encoding of characters on save

[Eli Zaretskii]

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.