* decoding more complex MIME messages
@ 2004-10-18 17:17 David Edmondson
2004-10-18 23:03 ` Katsumi Yamaoka
2004-12-30 1:31 ` Geoff Kuenning
0 siblings, 2 replies; 5+ messages in thread
From: David Edmondson @ 2004-10-18 17:17 UTC (permalink / raw)
[ Gnus 5.10.6 on Emacs 21.3.1 ]
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. 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.
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.
Footnotes:
[1] From newspipe: http://newspipe.sourceforge.net.
dme.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: decoding more complex MIME messages
2004-10-18 17:17 decoding more complex MIME messages David Edmondson
@ 2004-10-18 23:03 ` Katsumi Yamaoka
2004-12-30 1:31 ` Geoff Kuenning
1 sibling, 0 replies; 5+ messages in thread
From: Katsumi Yamaoka @ 2004-10-18 23:03 UTC (permalink / raw)
Cc: ding
>>>>> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: decoding more complex MIME messages
2004-10-18 17:17 decoding more complex MIME messages David Edmondson
2004-10-18 23:03 ` Katsumi Yamaoka
@ 2004-12-30 1:31 ` Geoff Kuenning
2005-01-05 13:21 ` nnml question G.Ananth Somayaji
1 sibling, 1 reply; 5+ messages in thread
From: Geoff Kuenning @ 2004-12-30 1:31 UTC (permalink / raw)
[ Gnus 5.9.0 on Emacs 21.3.1 ]
I'm also having trouble with nested MIME mail. My structure is a bit
different from David's. One example, generated by Outlook Express
6.00.2900.2180, is:
multipart/related {
multipart/alternative {
text/plain
text/html
}
image/jpeg
}
The other, generated by some Kodak software on a Mac that doesn't
produce an X-Mailer header, is:
multipart/mixed {
multipart/related {
multipart/alternative {
[unspecified content-type containing plain text]
text/html
}
image/jpeg
...
}
}
Gnus 5.9.0 doesn't seem to have mm-w3m-* functions. Is there a place
where I could back-fit David's fix, or am I stuck until I can upgrade
to a newer release?
--
Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
Perl is awk with skin cancer.
-- Henry Spencer
^ permalink raw reply [flat|nested] 5+ messages in thread
* nnml question
2004-12-30 1:31 ` Geoff Kuenning
@ 2005-01-05 13:21 ` G.Ananth Somayaji
2005-01-05 18:54 ` Tassilo Horn
0 siblings, 1 reply; 5+ messages in thread
From: G.Ananth Somayaji @ 2005-01-05 13:21 UTC (permalink / raw)
Hi,
Possible newbie question. How do I delete messages which have been delivered
by POP. something like storing to /dev/null. I am unable to create a nnml
folder to /dev/null.
-Ananth
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nnml question
2005-01-05 13:21 ` nnml question G.Ananth Somayaji
@ 2005-01-05 18:54 ` Tassilo Horn
0 siblings, 0 replies; 5+ messages in thread
From: Tassilo Horn @ 2005-01-05 18:54 UTC (permalink / raw)
"G.Ananth Somayaji" <gs_ananth@ti.com> writes:
> Possible newbie question. How do I delete messages which have been
> delivered by POP. something like storing to /dev/null. I am unable to
> create a nnml folder to /dev/null.
Have a look at (info "(gnus)6.3.6 Fancy Mail Splitting") and especially
at the symbol 'junk'.
,----[ C-h v nnmail-split-fancy RET ]
|
| junk: Mail will be deleted. Use with care! Do not submerge in water!
| Example:
| (setq nnmail-split-fancy
| '(| ("Subject" "MAKE MONEY FAST" junk)
| ...other.rules.omitted...))
`----
HTH,
Tassilo
--
"It may just be paranoia, but I think Gnus reads my mail."
Bruce Stephens <bruce@cenderis.demon.co.uk>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-01-05 18:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-18 17:17 decoding more complex MIME messages David Edmondson
2004-10-18 23:03 ` Katsumi Yamaoka
2004-12-30 1:31 ` Geoff Kuenning
2005-01-05 13:21 ` nnml question G.Ananth Somayaji
2005-01-05 18:54 ` Tassilo Horn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).