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

[Kenichi Handa]

In article <E1PdM2b-00011L-Cr@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> 
writes:

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

I don't want to modify rfc2047.el nor mm-util.el now.  So,
I've just installed a little bit inefficient workaround
which does this:

After decoding each header, if rmail-mime-coding-system is
nil, set it to a cons (CODING-SYSTEM . nil).

After decoding each body, if rmail-mime-coding-system is nil
or a cons, set it to CODING-SYSTEM.

After decoding a whole message, if rmail-mime-coding-system
is a cons (i.e. only a header part is decoded), re-decode
the header while binding mm-charset-override-alist to nil,
and set rmail-mime-coding-system to last-coding-system-used.

Set buffer-file-coding-system to rmail-mime-coding-system.

By this, encoding specified for a body always takes
precedence which I think is the right thing.

---
Kenichi Handa
handa@m17n.org