67/1bd49d3ddf1e1cce11909dbc335fab53c9a126

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 8C5B34196F2\r
   6         for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 10:21:44 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id XBHxBJZblwk4; Wed, 14 Apr 2010 10:21:43 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 5BF50431FC1;\r
  19         Wed, 14 Apr 2010 10:21:43 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id 02A68568DE1; Wed, 14 Apr 2010 10:21:43 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Dirk Hohndel <hohndel@infradead.org>, notmuch@notmuchmail.org\r
  24 Subject: Re: [PATCH] Next attempt to get guessing of From addresses correct in\r
  25         replies\r
  26 In-Reply-To: <m37hogdyr3.fsf@x200.gr8dns.org>\r
  27 References: <m37hogdyr3.fsf@x200.gr8dns.org>\r
  28 Date: Wed, 14 Apr 2010 10:21:42 -0700\r
  29 Message-ID: <87y6gqeyqh.fsf@yoom.home.cworth.org>\r
  30 MIME-Version: 1.0\r
  31 Content-Type: multipart/signed; boundary="=-=-=";\r
  32         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  33 X-BeenThere: notmuch@notmuchmail.org\r
  34 X-Mailman-Version: 2.1.13\r
  35 Precedence: list\r
  36 List-Id: "Use and development of the notmuch mail system."\r
  37         <notmuch.notmuchmail.org>\r
  38 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  39         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  40 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  41 List-Post: <mailto:notmuch@notmuchmail.org>\r
  42 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  43 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  45 X-List-Received-Date: Wed, 14 Apr 2010 17:21:44 -0000\r
  46 \r
  47 --=-=-=\r
  48 Content-Transfer-Encoding: quoted-printable\r
  49 \r
  50 On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel <hohndel@infradead.org> wr=\r
  51 ote:\r
  52 > + * WARNING - if the caller is asking for a header that could occur\r
  53 > + * multiple times than they MUST first call this function with a=20\r
  54 > + * a value of NULL for header_desired to ensure that all of the\r
  55 > + * headers are parsed and concatenated before a match is returned\r
  56 ...\r
  57 > +     } else {\r
  58 > +         /* not sure this makes sense for all headers that can occur\r
  59 > +          * multiple times, but for now just concatenate headers\r
  60 > +          */\r
  61 > +         newhdr =3D strlen(decoded_value);\r
  62 > +         hdrsofar =3D strlen(header_sofar);\r
  63 \r
  64 I'm a little nervous about this semantic change.\r
  65 \r
  66 For example, I know that my mail collection contains at least some\r
  67 messages with multiple Message-ID headers, (I'm not sure that's legal,\r
  68 but they are there). I found those when doing detailed comparisons of\r
  69 the database created by sup with that created by very early versions of\r
  70 what became the indexing code for notmuch. [Sup prefers the\r
  71 last-encountered Message-Id in the file, while Notmuch prefers the\r
  72 first.]\r
  73 \r
  74 So I'm concerned about the change above introducing subtle problems that\r
  75 might be hard to notice.\r
  76 \r
  77 How about an argument that asks explicitly for concatenated header\r
  78 values, (and this could just trigger a rescan of the headers and ignore\r
  79 the hash). I think that will be fine for your use case where you're just\r
  80 opening this message file to get this one concatenated header out,\r
  81 right?\r
  82 \r
  83 =2DCarl\r
  84 \r
  85 --=-=-=\r
  86 Content-Type: application/pgp-signature\r
  87 \r
  88 -----BEGIN PGP SIGNATURE-----\r
  89 Version: GnuPG v1.4.10 (GNU/Linux)\r
  90 \r
  91 iD8DBQFLxfmm6JDdNq8qSWgRAqgDAJ9T4YIhtfzgOrpyc8c+o+Ru0QvmdQCgg90Z\r
  92 8ADkr/6JZ6jI7Jh96O7ZB7c=\r
  93 =2Wj0\r
  94 -----END PGP SIGNATURE-----\r
  95 --=-=-=--\r