Hello,

I had many opportunities to need to see attachments containing
non-ASCII text or parts which have been compressed by gzip or
bzip2.  ARISAWA Akihiro suggested one solution to make it handy;
it was setting of the `gnus-summary-show-article-charset-alist'
variable as follows:

(setq gnus-summary-show-article-charset-alist
      '((0 . undecided)
	(1 . shift_jis)
	(2 . iso-2022-7bit)
	(3 . euc-japan)
	(4 . utf-8)))

It is very useful, especially for Japanese.  I can see a part
containing Japanese text (e.g., it is an ELisp program, a patch,
etc.) by typing `0 i' (or `1 i', `2 i',...) on the part button.
Still, I had to save a compressed part to a file and to use the
`less' command or something in order to see it.

On the other hand, TSUCHIYA Masatoshi proposed an idea that Gnus
supports sending and receiving the MIME charsets even for
attachments.  It seemed to be useful although there aren't
necessarily the MIME charsets corresponding to all the coding
systems (for example, there's no MIME charset for the
iso-2022-7bit coding system which is used in the etc/HELLO file).

I hit on another idea while considering about it last week.  The
plan is to add the charset parameter to the MIME header of an
attachment part automatically if there is a coding cookie in the
file and the MIME charset corresponding to it exists.  Even if
it cannot be done automatically, Gnus should recognize the
charset parameter which a user may add to the MML tag manually.
And then, Gnus will be able to decode and display such a part in
which the charset parameter is specified.  In addition to this,
I also noticed Gnus can decode an attachment if the coding
cookie is there even if the charset parameter is not specified.

I've installed them (including decompressing of compressed parts)
in the Gnus trunk.  Here are two examples compressed by gzip and
bzip2.  You can see them by simply typing `i' at the part buttons.
The charset parameter in the first part was added manually, and
the one in the second part was added automatically.