Re: [bugfixed] mm-charset-override-alist isn't used in decoding headers

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> Reiner Steib wrote:
> On Wed, Dec 10 2008, Katsumi Yamaoka wrote:

>> (Note that that I mention here is the `gbk' charset, not the `gbk'
>>  coding system.  So, `mm-charset-to-coding-system' is the best
>>  choice for checking whether it is available or not.  However,
>>  when loading mm-util,elc the default value section and/or the
>>  `:set' section of `(defcustom mm-charset-override-alist ...)'
>>  are processed before defining that function.)

> Would it help to move the defcustom down (or the defun up)?  Or would
> this introduce other problems?

Thanks.  There were two other reasons that made me hesitate to
add the `(gb2312 . gbk)' pair to `mm-charset-override-alist':

1. In Emacs 22 the `gbk' charset is available because of
`mm-charset-synonym-alist', however it does not support gbk
characters fully.  For example:

(rfc2047-decode-string "=?gbk?B?m3I=?=")
 => "\x9br"

2. In XEmacs 21.4 w/o the Mule feature,
(mm-charset-to-coding-system 'gbk) returns the symbol `gbk'.

But I decided to consider that 1. is not due to a Gnus bug, and
realized 2. is not a real problem (it won't get to be a straight
cause of an error, and it is a matter of course that non-Mule
XEmacs doesn't display gbk messages correctly).

So I've added the `(gb2312 . gbk)' pair to the default value of
`mm-charset-override-alist' for Emacsen that supports gbk, having
moved `mm-charset-to-coding-system' and `mm-charset-eval-alist'
forward.  In addition, I've added the optional argument `silent'
to `mm-charset-to-coding-system' so that it may not issue a warning
message when examining whether gbk is available.

Regards,