bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently

[Eli Zaretskii <eliz@gnu.org>]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 7626@debbugs.gnu.org
> Date: Thu, 13 Jan 2011 10:21:33 +0900
> 
> I found that rfc2047-decode-region (called while preparing
> the message header) sets last-coding-system-used to
> windows-1252.  That is because mm-util.el defines
> mm-charset-override-alist as this:
> 
>   '((gb2312 . gbk)
>     (iso-8859-1 . windows-1252)
>     (iso-8859-8 . windows-1255)
>     (iso-8859-9 . windows-1254))
> 
> And explains it as this:
> 
> i.e. treat iso-8859-1 as windows-1252.  windows-1252 is a
> superset of iso-8859-1."

I guess this is because some broken mailers state Latin-N while
actually using the corresponding Windows codepage, and when the
message includes characters not in Latin-N, they are not displayed
correctly.

But even if we keep this "feature" (see below for an alternative
suggestion), I don't see a need to force this on users.  We should
have a user option to do this.  Personally, I think it should be off
by default, but if someone feels strongly about that, I won't mind
having it on by default, in which case I will customize it on my
system.

> At the moment, I don't know how (or where) to fix this
> problem, but at least, it seems that setting
> buffer-file-coding-system to windows-1252 for iso-8859-1
> message won't cause an actual problem.

It's surprising and kludgey, IMO.  A better solution would be to
decode by windows-12XX, but set last-coding-system-used to Latin-N.
That way, only if I reuse the text that is not encodable by Latin-N, I
will need to do something.  Otherwise, I get to have the cake and eat
it, too.