11/0076efc6a1d959b6e8d3438a2a8e3e71726092

   1 Return-Path: <david@tethera.net>\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 arlo.cworth.org (Postfix) with ESMTP id 906F06DE02A7\r
   6  for <notmuch@notmuchmail.org>; Sat,  2 Apr 2016 05:41:21 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.021\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5\r
  12  tests=[AWL=-0.010, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
  13  autolearn=disabled\r
  14 Received: from arlo.cworth.org ([127.0.0.1])\r
  15  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16  with ESMTP id 8ainMvz3b9bJ for <notmuch@notmuchmail.org>;\r
  17  Sat,  2 Apr 2016 05:41:13 -0700 (PDT)\r
  18 Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
  19  by arlo.cworth.org (Postfix) with ESMTPS id CEF6F6DE0281\r
  20  for <notmuch@notmuchmail.org>; Sat,  2 Apr 2016 05:41:12 -0700 (PDT)\r
  21 Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
  22  (envelope-from <david@tethera.net>)\r
  23  id 1amKs4-00023V-87; Sat, 02 Apr 2016 08:41:44 -0400\r
  24 Received: (nullmailer pid 2988 invoked by uid 1000);\r
  25  Sat, 02 Apr 2016 12:41:08 -0000\r
  26 From: David Bremner <david@tethera.net>\r
  27 To: David Mazieres expires 2016-06-30 PDT\r
  28  <mazieres-fmzyazpz6acxdkzys7pkrhp8ve@temporary-address.scs.stanford.edu>,\r
  29  notmuch@notmuchmail.org\r
  30 Subject: Re: Breaking a really long thread\r
  31 In-Reply-To: <87twjkopb8.fsf@ta.scs.stanford.edu>\r
  32 References: <1459015043-8460-1-git-send-email-david@tethera.net>\r
  33  <87twjkopb8.fsf@ta.scs.stanford.edu>\r
  34 User-Agent: Notmuch/0.21+74~g6c60fb1 (http://notmuchmail.org) Emacs/24.5.1\r
  35  (x86_64-pc-linux-gnu)\r
  36 Date: Sat, 02 Apr 2016 09:41:08 -0300\r
  37 Message-ID: <87a8lci3ob.fsf@zancas.localnet>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: text/plain\r
  40 X-BeenThere: notmuch@notmuchmail.org\r
  41 X-Mailman-Version: 2.1.20\r
  42 Precedence: list\r
  43 List-Id: "Use and development of the notmuch mail system."\r
  44  <notmuch.notmuchmail.org>\r
  45 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  46  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  47 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  48 List-Post: <mailto:notmuch@notmuchmail.org>\r
  49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  50 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  51  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  52 X-List-Received-Date: Sat, 02 Apr 2016 12:41:21 -0000\r
  53 \r
  54 David Mazieres <dm-list-email-notmuch@scs.stanford.edu> writes:\r
  55 \r
  56 \r
  57 > Is there any way to break an existing thread (so as to start over with a\r
  58 > smaller thread), or otherwise to tweak the threading rules so that a\r
  59 > particular References header gets ignored.\r
  60 \r
  61 Currently there is no way to do this, as threads are "stateless"\r
  62 i.e. created on the fly by _notmuch_create_thread based only on\r
  63 immutable mail data.  We'd have to be willing to dump/restore any\r
  64 threading hints we added to the database, but we're already headed down\r
  65 that path with the libconfig stuff anyway.  Something we _almost_ have\r
  66 the infrastructure in place for would be to blacklist a particular\r
  67 reference (e.g. by regex) by storing the blacklist as database\r
  68 metadata. That would solve your particular problem, although I'm not\r
  69 sure it it's general enough. Keeping global state for all thread\r
  70 breaking sounds a bit clunky.\r
  71 \r
  72 > It's annoyingly slow to open\r
  73 > a thread with 10,000 messages just to read one SMS.  I'm almost tempted\r
  74 > to mangle the messages on delivery and remove the References header\r
  75 > before notmuch sees them, but it would be nice to have a cleaner\r
  76 > solution, as there are other situations in which one might want to\r
  77 > "reset" a really long thread.\r
  78 \r
  79 Like this thread ;).\r