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

[Stefan Monnier]

> Several reasons off the top of my head:
>   . It gives you an easily visible indication of how the message was
>     encoded.  (We hide the relevant mail headers by default, so they
>     are not visible unless you invoke rmail-toggle-header.)

So it's abusing buffer-file-coding-system for "message-coding-system"
(which of course is only meaningful is the message is not made up of
various parts using different coding-systems).

>   . It is useful when saving the current message to a file.

Good point.

>   . When replying to a message, rmail-reply uses it to set the
>     encoding of the *mail* buffer where you compose the reply, which
>     takes care of 99.99% of situations where the response needs to
>     have some non-trivial encoding that is not your system's native
>     one.

rmail-replay doesn't need to use buffer-file-coding-system for that, but
could just as well use some other variable for it, right?

> The last one of these is by far the most important reason, at least in
> my use pattern.

Then it's easy to fix.

> Maybe we need to set up an after-save-hook to restore the original
> encoding after saving the message collection?

That would be fine, yes.  I'd suggest to use an rmail-coding-system
variable as the canonical place to store the coding system used for the
currently shown message, use it in rmail-reply in preference to
buffer-file-coding-system, and simply copy rmail-coding-system to
buffer-file-coding-system whenever necessary, such as in
after-save-hook.

> Btw, I find rmail-swap-buffers incomplete in its handling of encoding
> and the modified flag.  It looks like it works by sheer luck, unless
> I'm missing something.

Could be.  I really think the first thing that needs to be done is to
get rid of Rmail's constant swapping of those buffers.  There should be
one swap when entering rmail-mode and one more when(if) leaving it,
no more.  That will get us rid of most of that insanity.


        Stefan