[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently
Date: Thu, 13 Jan 2011 07:12:33 -0500

> From: Kenichi Handa <address@hidden>
> Cc: address@hidden
> 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

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

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]