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

[Shenghuo ZHU <zsh@cs.rochester.edu>]

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