Re: [PATCH] Next attempt to get guessing of From addresses correct in replies

diff --git a/67/1bd49d3ddf1e1cce11909dbc335fab53c9a126 b/67/1bd49d3ddf1e1cce11909dbc335fab53c9a126
new file mode 100644 (file)
index 0000000..72d7f0d
--- /dev/null
+++ b/67/1bd49d3ddf1e1cce11909dbc335fab53c9a126
@@ -0,0 +1,95 @@
+Return-Path: <cworth@cworth.org>\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 8C5B34196F2\r
+       for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 10:21:44 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.89\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
+       tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
+       autolearn=ham\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 XBHxBJZblwk4; Wed, 14 Apr 2010 10:21:43 -0700 (PDT)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 5BF50431FC1;\r
+       Wed, 14 Apr 2010 10:21:43 -0700 (PDT)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id 02A68568DE1; Wed, 14 Apr 2010 10:21:43 -0700 (PDT)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Dirk Hohndel <hohndel@infradead.org>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH] Next attempt to get guessing of From addresses correct in\r
+       replies\r
+In-Reply-To: <m37hogdyr3.fsf@x200.gr8dns.org>\r
+References: <m37hogdyr3.fsf@x200.gr8dns.org>\r
+Date: Wed, 14 Apr 2010 10:21:42 -0700\r
+Message-ID: <87y6gqeyqh.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; 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: Wed, 14 Apr 2010 17:21:44 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel <hohndel@infradead.org> wr=\r
+ote:\r
+> + * WARNING - if the caller is asking for a header that could occur\r
+> + * multiple times than they MUST first call this function with a=20\r
+> + * a value of NULL for header_desired to ensure that all of the\r
+> + * headers are parsed and concatenated before a match is returned\r
+...\r
+> +    } else {\r
+> +        /* not sure this makes sense for all headers that can occur\r
+> +         * multiple times, but for now just concatenate headers\r
+> +         */\r
+> +        newhdr =3D strlen(decoded_value);\r
+> +        hdrsofar =3D strlen(header_sofar);\r
+\r
+I'm a little nervous about this semantic change.\r
+\r
+For example, I know that my mail collection contains at least some\r
+messages with multiple Message-ID headers, (I'm not sure that's legal,\r
+but they are there). I found those when doing detailed comparisons of\r
+the database created by sup with that created by very early versions of\r
+what became the indexing code for notmuch. [Sup prefers the\r
+last-encountered Message-Id in the file, while Notmuch prefers the\r
+first.]\r
+\r
+So I'm concerned about the change above introducing subtle problems that\r
+might be hard to notice.\r
+\r
+How about an argument that asks explicitly for concatenated header\r
+values, (and this could just trigger a rescan of the headers and ignore\r
+the hash). I think that will be fine for your use case where you're just\r
+opening this message file to get this one concatenated header out,\r
+right?\r
+\r
+=2DCarl\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iD8DBQFLxfmm6JDdNq8qSWgRAqgDAJ9T4YIhtfzgOrpyc8c+o+Ru0QvmdQCgg90Z\r
+8ADkr/6JZ6jI7Jh96O7ZB7c=\r
+=2Wj0\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r