TL;DR: I had a MIMEpiphany and I'm sending a new version of this series that I think will address your concerns. Quoth Jameson Graef Rollins on Mar 03 at 2:05 pm: > Hey, Austin. As always, thank you so much for your hard work on this > rewrite. It looks like things are definitely moving the right > direction. > > I haven't done a full review of this patch set, and I've been pretty out > of the loop on this stuff recently, but I do notice that there are some > changes to the tests that don't look right to me. > > On Sat, 3 Mar 2012 00:20:25 -0500, Austin Clements <amdragon@MIT.EDU> wrote: > > This is fully compatible for root and leaf parts, but drops support > > for interior parts. Showing interior parts in raw has always been > > braindead broken, so I don't think anyone will miss this. Tests have > > been updated to reflect this. > > I think I'm confused about this "drop support for interior parts". What > constitutes an "interior part"? Aren't all parts interior? It looks > From the patch that maybe you're referring specifically to rfc822 parts? Interior parts are any part that isn't a root part (the whole message) or a leaf part. I had originally planned to simply deprecate raw in favor of two new formats: "body", which outputted just bodies with transfer decoding (which, for rfc822 parts, would include the attached message headers, but not the envelope headers) and "source", which outputted full parts with headers. I had been thinking that "source" would be necessary for fetching the entire message and "body" for fetching attachments and other leaf parts, but then it dawned on me that even trivial messages have two parts already: part 0 is an rfc822 part representing the whole message and part 1 is the body. Hence, modulo specialty uses like crypto, "body" was already sufficient for both uses *and* compatible with "raw" for root and leaf parts. I've updated my series to reflect this. Raw now works for any part. > > test_begin_subtest "--format=raw --part=4, rfc822's html part" > > -notmuch show --format=raw --part=4 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT > > +notmuch show --format=raw --part=4 'id:87liy5ap00.fsf@yoom.home.cworth.org' >&OUTPUT > > cat <<EOF >EXPECTED > > -<p>This is an embedded message, with a multipart/alternative part.</p> > > -This is an embedded message, with a multipart/alternative part. > > +Error: Raw only supports root and leaf parts > > EOF > > test_expect_equal_file OUTPUT EXPECTED > > Maybe this is ultimately a limitation of what we can expect the raw > formatter to do, but isn't this a leaf part? Actually that was a typo in the test name. Part 4 is a multipart, not a leaf part. The new series includes a patch for this.