cd/0aba0966eabe604018956a9f1b8db8848226fe

   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 93B6A431FB6\r
   6         for <notmuch@notmuchmail.org>; Tue, 12 Feb 2013 11:14:32 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id 6yAEgKhSGjB5 for <notmuch@notmuchmail.org>;\r
  16         Tue, 12 Feb 2013 11:14:32 -0800 (PST)\r
  17 Received: from arlo.cworth.org (arlo.cworth.org [50.126.95.6])\r
  18         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id 09EA2431FAF\r
  21         for <notmuch@notmuchmail.org>; Tue, 12 Feb 2013 11:14:32 -0800 (PST)\r
  22 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  23         by arlo.cworth.org (Postfix) with ESMTP id 0D0BE6DE0941;\r
  24         Tue, 12 Feb 2013 11:14:30 -0800 (PST)\r
  25 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  26         id 44C3E64933; Wed, 13 Feb 2013 06:17:18 +1100 (EST)\r
  27 From: Carl Worth <cworth@cworth.org>\r
  28 To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
  29         David Bremner <david@tethera.net>,\r
  30         Robert Mast <beheerder@tekenbeetziekten.nl>,\r
  31         'Jani Nikula' <jani@nikula.org>, notmuch@notmuchmail.org\r
  32 Subject: RE: Reply all - issue\r
  33 In-Reply-To: <87sj52nh6h.fsf@servo.finestructure.net>\r
  34 References: <000001cdfcd9$82500f00$86f02d00$@nl> <87wquxjq7k.fsf@nikula.org>\r
  35         <002601cdfd83$83b283f0$8b178bd0$@nl>\r
  36         <87boc8bt8a.fsf@yoom.home.cworth.org>\r
  37         <000001cdff33$afe11070$0fa33150$@nl>\r
  38         <87txpykve8.fsf@zancas.localnet> <87r4l2kvak.fsf@zancas.localnet>\r
  39         <87sj52nh6h.fsf@servo.finestructure.net>\r
  40 User-Agent: Notmuch/0.13.1 (http://notmuchmail.org) Emacs/23.4.1\r
  41         (x86_64-pc-linux-gnu)\r
  42 Date: Tue, 12 Feb 2013 11:17:08 -0800\r
  43 Message-ID: <877gmdjqa3.fsf@yoom.home.cworth.org>\r
  44 MIME-Version: 1.0\r
  45 Content-Type: multipart/signed; boundary="=-=-=";\r
  46         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  47 X-BeenThere: notmuch@notmuchmail.org\r
  48 X-Mailman-Version: 2.1.13\r
  49 Precedence: list\r
  50 List-Id: "Use and development of the notmuch mail system."\r
  51         <notmuch.notmuchmail.org>\r
  52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  54 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  55 List-Post: <mailto:notmuch@notmuchmail.org>\r
  56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  59 X-List-Received-Date: Tue, 12 Feb 2013 19:14:32 -0000\r
  60 \r
  61 --=-=-=\r
  62 Content-Type: text/plain; charset=utf-8\r
  63 Content-Transfer-Encoding: quoted-printable\r
  64 \r
  65 Jameson Graef Rollins <jrollins@finestructure.net> writes:\r
  66 > Just a thought: what if messages with a given tag (e.g. "new-thread")\r
  67 > were always treated as the source of a new thread?\r
  68 \r
  69 It's a good start. And an approach like that would have the advantage\r
  70 that one could undo a thread-split by just removing the tag. (That's not\r
  71 an explicit thread-join feature, but I don't think anyone has ever asked\r
  72 for that.)\r
  73 \r
  74 > A message with the given tag could just be (re)indexed with any\r
  75 > In-Reply-To/References headers stripped before indexing.\r
  76 \r
  77 It would require a little more than that. Imagine this thread:\r
  78 \r
  79   A: Subject: An original thread\r
  80   =E2=94=94=E2=94=80B: Subject: Thread hijacking is fun (tag:new-thread)\r
  81     =E2=94=94=E2=94=80C: Subject: Re: Thread hijacking is fun\r
  82 \r
  83 In this case, message C is likely to have a References header that\r
  84 mentions both A and B. So the thread stitching logic in notmuch will\r
  85 want to merge threads A and B when indexing C. So special care will have\r
  86 to be taken here as well, (not just when indexing B).\r
  87 \r
  88 And that special care may not be cheap if it requires additional\r
  89 database lookups for each unique thread ID encountered among references\r
  90 of a message.\r
  91 \r
  92 Though, I don't mean to dissuade anyone from thinking this through and\r
  93 coding it up. The relevant code for the pieces I'm referring to starts\r
  94 in _notmuch_database_link_message in lib/database.cc.\r
  95 \r
  96 =2DCarl\r
  97 \r
  98 =2D-=20\r
  99 carl.d.worth@intel.com\r
 100 \r
 101 --=-=-=\r
 102 Content-Type: application/pgp-signature\r
 103 \r
 104 -----BEGIN PGP SIGNATURE-----\r
 105 Version: GnuPG v1.4.12 (GNU/Linux)\r
 106 \r
 107 iEYEARECAAYFAlEalTQACgkQ6JDdNq8qSWguyQCfbtLt8QIx19Mjhbb7q/5BuEJe\r
 108 z5sAniG0T+bewnGDgmcAd+IUAQOJpD7Z\r
 109 =su3/\r
 110 -----END PGP SIGNATURE-----\r
 111 --=-=-=--\r