--- /dev/null
+Return-Path: <jrollins@finestructure.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 8D113431FAF\r
+ for <notmuch@notmuchmail.org>; Sat, 3 Mar 2012 14:06:05 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.29\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id i14ZJaFfndvm for <notmuch@notmuchmail.org>;\r
+ Sat, 3 Mar 2012 14:06:05 -0800 (PST)\r
+Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
+ [131.215.239.19])\r
+ by olra.theworths.org (Postfix) with ESMTP id D1ADC431FAE\r
+ for <notmuch@notmuchmail.org>; Sat, 3 Mar 2012 14:06:04 -0800 (PST)\r
+Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
+ by fire-doxen-postvirus (Postfix) with ESMTP id 2DEB2328041;\r
+ Sat, 3 Mar 2012 14:06:04 -0800 (PST)\r
+X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new\r
+Received: from finestructure.net (DHCP-123-180.caltech.edu [131.215.123.180])\r
+ (Authenticated sender: jrollins)\r
+ by fire-doxen-submit (Postfix) with ESMTP id 3B221328005;\r
+ Sat, 3 Mar 2012 14:06:01 -0800 (PST)\r
+Received: by finestructure.net (Postfix, from userid 1000)\r
+ id 07B821276; Sat, 3 Mar 2012 14:06:00 -0800 (PST)\r
+From: Jameson Graef Rollins <jrollins@finestructure.net>\r
+To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 5/5] show: Convert raw format to the new self-recursive\r
+ style\r
+In-Reply-To: <1330752025-2542-6-git-send-email-amdragon@mit.edu>\r
+References: <1330752025-2542-1-git-send-email-amdragon@mit.edu>\r
+ <1330752025-2542-6-git-send-email-amdragon@mit.edu>\r
+User-Agent: Notmuch/0.11.1+264~gb8fb66b (http://notmuchmail.org) Emacs/23.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sat, 03 Mar 2012 14:05:58 -0800\r
+Message-ID: <87zkbxqr09.fsf@servo.finestructure.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha256; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 03 Mar 2012 22:06:05 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+Hey, Austin. As always, thank you so much for your hard work on this\r
+rewrite. It looks like things are definitely moving the right\r
+direction.\r
+\r
+I haven't done a full review of this patch set, and I've been pretty out\r
+of the loop on this stuff recently, but I do notice that there are some\r
+changes to the tests that don't look right to me.\r
+\r
+On Sat, 3 Mar 2012 00:20:25 -0500, Austin Clements <amdragon@MIT.EDU> wrot=\r
+e:\r
+> This is fully compatible for root and leaf parts, but drops support\r
+> for interior parts. Showing interior parts in raw has always been\r
+> braindead broken, so I don't think anyone will miss this. Tests have\r
+> been updated to reflect this.\r
+\r
+I think I'm confused about this "drop support for interior parts". What\r
+constitutes an "interior part"? Aren't all parts interior? It looks\r
+From=20the patch that maybe you're referring specifically to rfc822 parts?\r
+\r
+I can understand not supporting output of multipart parts in raw; it's\r
+unclear what a "raw" multipart even is. But I think we do need to\r
+support common-sense handling of rfc822 parts, even if it requires\r
+special casing. These following two test modifications illustrate the\r
+issue:\r
+\r
+> test_begin_subtest "--format=3Draw --part=3D3, rfc822 part"\r
+> -test_subtest_known_broken\r
+> -\r
+> -notmuch show --format=3Draw --part=3D3 'id:87liy5ap00.fsf@yoom.home.cwor=\r
+th.org' >OUTPUT\r
+> -test_expect_equal_file OUTPUT embedded_message\r
+> +notmuch show --format=3Draw --part=3D3 'id:87liy5ap00.fsf@yoom.home.cwor=\r
+th.org' >&OUTPUT\r
+> +cat <<EOF >EXPECTED\r
+> +Error: Raw only supports root and leaf parts\r
+> +EOF\r
+> +test_expect_equal_file OUTPUT EXPECTED\r
+\r
+I pretty strongly think that this test needs to remain how it was. If\r
+someone forwards me a message as a rfc822 part I should be able to\r
+retrieve the full forwarded message directly, by e.g. redirecting it to\r
+a file and recreating the original message exactly intact. That's why I\r
+constructed this test the way I did originally, and left it\r
+known_broken. If we can't support this now that's fine, but I still\r
+think this test describes an important needed functionality that we\r
+should strive to support at some point. Maybe it needs an entirely new\r
+output formatter, or some special casing, but I still think it's\r
+reasonable to expect that we should support this.\r
+\r
+> test_begin_subtest "--format=3Draw --part=3D4, rfc822's html part"\r
+> -notmuch show --format=3Draw --part=3D4 'id:87liy5ap00.fsf@yoom.home.cwor=\r
+th.org' >OUTPUT\r
+> +notmuch show --format=3Draw --part=3D4 'id:87liy5ap00.fsf@yoom.home.cwor=\r
+th.org' >&OUTPUT\r
+> cat <<EOF >EXPECTED\r
+> -<p>This is an embedded message, with a multipart/alternative part.</p>\r
+> -This is an embedded message, with a multipart/alternative part.\r
+> +Error: Raw only supports root and leaf parts\r
+> EOF\r
+> test_expect_equal_file OUTPUT EXPECTED\r
+\r
+Maybe this is ultimately a limitation of what we can expect the raw\r
+formatter to do, but isn't this a leaf part? As with whole rfc822\r
+parts, I also expect that we should be able to retrieve interior leaf\r
+parts of rfc822 message parts. So I think I would prefer that this test\r
+just move to test_subtest_known_broken until a better way to handle this\r
+is figured out.\r
+\r
+Without looking into the details of your whole show rewrite, I'm\r
+guessing that we just can't reasonably expect the raw formatter to\r
+handle rfc822 parts the way we need. Is that correct? Is there some\r
+other formatter that might be better suited for this? Like I say, I\r
+think it's ok if we have to have some special casing for this particular\r
+type of part. But either way I think we should try to support handling\r
+rfc822 parts in a useful way.\r
+\r
+jamie.\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iQIcBAEBCAAGBQJPUpXGAAoJEO00zqvie6q8SxYP/3q6IAbQc9OSzTNiGRzvjo/k\r
+posFVhzBrvI4BsgFWK4buYwyOKtP2YQGp4RuN047iRpKoxL3X6+R1GQk1avCx8Ov\r
+2g89P03Hv+LPcXVyQ65wk7zGwIrlSBtDGR4NsTXg7LXs35PX368m+WeiiFBZmA8S\r
+bcDllCUuDe49HNqX/CVOYuxksC+OTdIEUnuPwnE1Ahi+mVOxmkqFyzdapfAn3BKd\r
+tywqmzrZzJ5tTo2Nepgl5q7bWnXvpZ7vpW6xHbRMWojZuYtn7D2UAgfLordI57ih\r
+xI9cesrc7omysPjWB6pk+7sDX1t25f9q1yxyLnlkUK0CobkrGcA2IQTNVUIieEI/\r
+ZBU28znNsyCMH+WIFL8xkCpSzNUn5wduwvtpTUIkPUEQ4jn3tkXR1Vr2VKgLRPgp\r
+jSyRtEnS3Wg0l8nmB+QK7u7ljZE6yd3XbjfQj0D+D0ZJVuxtzeKHUKK+uOwQK+Tb\r
+JMtVlVXwMF4dHEG4uvADvklXdI4+vhEKtxVEoTxhgK5rO0ttFReQ27u47e2twBGp\r
+I+n2Jdp6tuRftcqe+hwXo7laj/ShRjE7I0rksejqCLEKv3EmuquNAEFtcU0ioDO6\r
+bV6Clkk+26QcwkP8PMgdpyiEsW5zvTUZBc0aSW+N39/8PzbJ+bXYmrZZIw3De/eA\r
+gXj99B/CYR/QXg8AlY/P\r
+=cwLz\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r