gnus-article-view-part-as-charset doesn't handle multipart properly.

gnus-article-view-part-as-charset doesn't handle multipart properly.

[Alex Bochannek]

In "No Gnus v0.6" I noticed problems with 'K C' on certain messages. I
would enter a charset, but then receive the error:

 Wrong type argument: consp, nil

At that point I couldn't display any further messages or even quit the
group. I traced it down to a problem in
gnus-article-view-part-as-charset, which accidentally truncates the
handle list for multipart messages. The truncated list would then fail
the display function, but also mm-destroy-parts.

The problem seems to be in here:

	;; Strip the charset parameter from `handle'.
	(setq type (mm-handle-type
		    (if (equal (mm-handle-media-type handle)
			       "message/external-body")
			(progn
			  (unless (mm-handle-cache handle)
			    (mm-extern-cache-contents handle))
			  (mm-handle-cache handle))
		      handle))
	      charset (assq 'charset (cdr type)))
	(delq charset type)

It turns out that for multiparts, type ends up being the handle for the
buffer of the part and not the sublist that include the charset
list. Therefore, assq fails, charset is nil, and delq removes all
trailing nil elements of the list.

For example, in a single part HTML message, handle looks like this:

(#<buffer  *mm*>
	   ("text/html"
	    (charset . "us-ascii"))
	   nil
	   (lambda nil
	     (let
		 (buffer-read-only)
	       (if
		   (functionp 'remove-specifier)
		   (mapcar
		    (lambda
		      (prop)
		      (remove-specifier
		       (face-property 'default prop)
		       (current-buffer)))
		    '(background background-pixmap foreground)))
	       (delete-region #<marker at 318 in *Article*> #<marker at 16266 in *Article*>)))
	   nil nil nil nil)

and the charset can easily be extracted.

However a multipart handle looks like this:

(#("multipart/alternative" 0 21
   (start nil from "..." buffer #<buffer  *mm*> boundary "----------012345678901234"))
 (#<buffer  *mm*<2>>
	    ("text/plain"
	     (charset . "iso-8859-1"))
	    7bit nil nil nil nil nil)
 (#<buffer  *mm*<3>>
	    ("text/html"
	     (charset . "iso-8859-1"))
	    7bit
            ....

The assq of the cdr will obviously fail, and the delq results in:

(#<buffer  *mm*<2>>
	   ("text/plain"
	    (charset . "iso-8859-1"))
	   7bit)

I haven't looked at the code for long enough to suggest a patch, but I
am hoping that Katsumi might have some more insight since this chunk of
code was committed by him last year.

Thanks,

Alex.

Re: gnus-article-view-part-as-charset doesn't handle multipart properly.

[Katsumi Yamaoka]

Hi,

I've made changes in gnus-art.el and mm-view.el in both the trunk
and the v5-10 branch.  Miles, please merge those changes into Emacs
if it is still possible.

>>>>> In <ysmsk5waxvof.fsf@alexb-lt.jnpr.net> Alex Bochannek wrote:

> In "No Gnus v0.6" I noticed problems with 'K C' on certain messages. I
> would enter a charset, but then receive the error:

>  Wrong type argument: consp, nil

> At that point I couldn't display any further messages or even quit the
> group. I traced it down to a problem in
> gnus-article-view-part-as-charset, which accidentally truncates the
> handle list for multipart messages. The truncated list would then fail
> the display function, but also mm-destroy-parts.

That's serious.  To kill the article buffer might be the only
way of escaping from the problem.

> The problem seems to be in here:

Thank you very much for investigating this.  It happens if an
article has a multipart message containing nested MIME parts.
The most common one is a multipart/alternative message which
contains a text/plain part and a text/html part[1] as you
mentioned.  But now Gnus works no matter how MIME parts are
nested.

I've also fixed other two bugs.  One is to make the `K C' command
redisplay the subpart that is currently displayed, not another
subpart, of multipart/alternative part.  The other is to make
the `K C' command and the `C' command (which is available in the
article buffer) pass a charset, which a user specified, to the
html renderer `w3m', `w3m-standalone', or `html2text'[2].

Regards,

[1] I noticed Gnus doesn't completely work with a
multipart/alternative part containing three or more subparts.

[2] `links' and `lynx' don't seem to support non-ASCII text, e.g.,
Japanese.  And the renderer for Emacs/W3 seems to have been
designed to always prefer the charset specified in the META tag.