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

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

[Vladimir Volovich]

[-- Attachment #1: Type: text, Size: 480 bytes --]

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

[Shenghuo ZHU]

>>>>> "VVV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes:

VVV> this did not help either. no changes; i see
VVV> \301\305\302... instead of russian chars in those broken
VVV> messages. note that when there is absolutely no content-type
VVV> header, gnus shows russian characters right (by default in
VVV> koi8-r). but i those message there was a content-type header, but
VVV> it was broken: it contained "text". in some earlier versions of
VVV> pgnus these messages were shown right.

You means there is "Content-type: text" in header?  So you can see a
[1. text] button in *Article* buffer. Am I right?

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

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

There is a bug when you click the button 4 times. A patch is attached.

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

The documentation is incorrect.

-- 
Shenghuo

ChangeLog:

Wed Dec  9 15:18:39 1998  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mm-decode.el (mm-display-part): Forward a line.

:- cut ----
--- mm-decode.el	1998/12/09 20:17:55	1.1
+++ mm-decode.el	1998/12/09 20:18:18
@@ -236,7 +236,8 @@
 	(if (eq user-method 'inline)
 	    (progn
 	      (forward-line 1)
-	      (mm-display-inline handle))
+	      (mm-display-inline handle)
+	      'inline)
 	  (when (or user-method
 		    method
 		    (not no-default))
@@ -244,6 +245,7 @@
 		     (not method)
 		     (equal "text" (car (split-string type))))
 		(progn
+		  (forward-line 1)
 		  (mm-insert-inline handle (mm-get-part handle))
 		  'inline)
 	      (mm-display-external

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

[Vladimir Volovich]

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

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

[Vladimir Volovich]

"ZSH" == Shenghuo ZHU writes:

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

btw, it would be nice to be able to force decoding for a given charset
for a non-multipart messages, too (in cases when charset was specified
incorrectly by a broken MUA). [for non-multipart messages there are no
buttons, and `i' is not working]

	Best regards, -- Vladimir.

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

[Michael Welsh Duggan]

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> "ZSH" == Shenghuo ZHU writes:
> 
>  ZSH> There is a trick to show the decoded content. Press 'i' on the
>  ZSH> button, then 'C-u i koi8-r RET'.
> 
> btw, it would be nice to be able to force decoding for a given charset
> for a non-multipart messages, too (in cases when charset was specified
> incorrectly by a broken MUA). [for non-multipart messages there are no
> buttons, and `i' is not working]

`C-u W M c' doesn't work?

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.

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

[Vladimir Volovich]

"MWD" == Michael Welsh Duggan writes:

 >> btw, it would be nice to be able to force decoding for a given
 >> charset for a non-multipart messages, too (in cases when charset
 >> was specified incorrectly by a broken MUA). [for non-multipart
 >> messages there are no buttons, and `i' is not working]

 MWD> `C-u W M c' doesn't work?

Hmm [i did not know about `W M c']. Here is what i get:

* if the article is already decoded (maybe, wrongly), then pressing
  `C-u W M c' and specifying another charset causes buggy
  double-decoding (resulting in \214<8-bit-char> mess)

* to deal with the above [is it a bug?] i can do `C-u g' an article
  before pressing `C-u W M c'.

* and most important, this does not work for the article which started
  this thread: pressing `C-u W M c' and specifying any charset has no
  effect at all --- an article remains unencoded (i.e. looks like
  `\301\305\302...'). this is perhaps a bug.

	Best regards, -- Vladimir.