Re: test message: broken content-type & 8-bit messages

[Vladimir Volovich <vvv@vvv.vsu.ru>]

"ZSH" == Shenghuo ZHU writes:

 ZSH> You means there is "Content-type: text" in header?

yes.

 ZSH> So you can see a [1. text] button in *Article* buffer. Am I
 ZSH> right?

no, i cannot see such a button even if i use `M-t' or `K b' (at least
in nnmbox backend). [see my first message in this thread]

 ZSH> If so, the content is not supposed to be decoded, since the
 ZSH> minor type of content is unknown. The mm-insert-inline is called
 ZSH> instead of mm-inline-text.

that's the whole point of rfc2047-default-charset and/or
gnus-default-charset? i.e. in the text messages with unspecified
charset or with broken syntax of c-t header or if 8-bit chars are
present while c-t claims that charset is us-ascii. or am i missing
something? gnus should treat 8-bit (non-ASCII) chars as encoded in
rfc2047-default-charset in such situations.

 ZSH> There is a trick to show the decoded content. Press 'i' on the
 ZSH> button, then 'C-u i koi8-r RET'.

i do not see a button, --- see my first message in this thread.

 VVV> btw: from documentation on gnus-default-charset: Default charset
 VVV> assumed to be used when viewing non-ASCII characters.  This
 VVV> variable is used only in non-Mule Emacsen.  but i do use mule
 VVV> (emacs 20.3 with mule).

 ZSH> The documentation is incorrect.

then, what is the difference betweem rfc2047-default-charset and
gnus-default-charset? both are defined in gnus...

	Best regards, -- Vladimir.