Re: decoding more complex MIME messages

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> In <x74qksgd4j.fsf@tarte-tatin.hollytree-house.co.uk> David Edmondson wrote:

> I receive some mail messages[1] that have the following form:

> multipart/alternative {
>   text/plain
>   multipart/related {
>     text/html
>     image/jpeg
>     image/jpeg
>     ...
>}
>}

> My preference is to read the HTML version with inline embedded
> images.  Unfortunately the code that searches for the images doesn't
> find them, as they are nested too deeply.

I see.  It can be complicated infinitely, though I haven't seen
such an article yet.

> As a result, I modified mm-w3m-cid-retrieve-1:

> (defun mm-w3m-cid-retrieve-1 (url handle)
>   (dolist (elem handle)
>     (when (listp elem)
>       (if (equal url (mm-handle-id elem))
> 	  (progn
> 	    (mm-insert-part elem)
> 	    (throw 'found-handle (mm-handle-media-type elem))))
>       (if (equal "multipart" (mm-handle-media-supertype elem))
> 	  (mm-w3m-cid-retrieve-1 url elem)))))

> In essence, if one of the sub-parts of the element being examined is a
> multipart, we descend into the multipart to search.

That's a great improvement.  I couldn't find any doubt in it.

> Could someone check this and, as appropriate, correct it, improve it
> or commit it?  I've previously signed FSF papers for Gnus I believe,
> if that's relevant.

I've installed it in the Gnus trunk and the v5-10 branch.  Thank
you very much for the contribution.