1d/ced0615cf7aac6c277227b15cc239f55b05420

   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 8860C431FC2;\r
   6         Thu, 10 Dec 2009 21:39:36 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id 9O1v2HHtCzfR; Thu, 10 Dec 2009 21:39:35 -0800 (PST)\r
  11 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  12         by olra.theworths.org (Postfix) with ESMTP id 7C167431FAE;\r
  13         Thu, 10 Dec 2009 21:39:35 -0800 (PST)\r
  14 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  15         id AD19B2542FF; Thu, 10 Dec 2009 13:30:13 -0800 (PST)\r
  16 From: Carl Worth <cworth@cworth.org>\r
  17 To: Marten Veldthuis <marten@veldthuis.com>, Mark Anderson\r
  18         <markr.anderson@amd.com>, notmuch <notmuch@notmuchmail.org>\r
  19 In-Reply-To: <87ljha3avx.fsf@home.veldthuis.com>\r
  20 References: <1260400470-sup-5775@testarossa>\r
  21         <87ws0ug23f.fsf@yoom.home.cworth.org>\r
  22         <87ljha3avx.fsf@home.veldthuis.com>\r
  23 Date: Thu, 10 Dec 2009 13:30:13 -0800\r
  24 Message-ID: <87ocm64ivu.fsf@yoom.home.cworth.org>\r
  25 MIME-Version: 1.0\r
  26 Content-Type: multipart/signed; boundary="=-=-=";\r
  27         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  28 Subject: Re: [notmuch] Threading\r
  29 X-BeenThere: notmuch@notmuchmail.org\r
  30 X-Mailman-Version: 2.1.12\r
  31 Precedence: list\r
  32 List-Id: "Use and development of the notmuch mail system."\r
  33         <notmuch.notmuchmail.org>\r
  34 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  35         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  36 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  37 List-Post: <mailto:notmuch@notmuchmail.org>\r
  38 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  39 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  40         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  41 X-List-Received-Date: Fri, 11 Dec 2009 05:39:37 -0000\r
  42 \r
  43 --=-=-=\r
  44 \r
  45 On Thu, 10 Dec 2009 20:08:18 +0100, Marten Veldthuis <marten@veldthuis.com> wrote:\r
  46 > On a related note, what about communicating with people who press reply\r
  47 > on an existing message, change the subject and start a new mail\r
  48 > thread. Most mail clients will still insert the In-Reply-To header,\r
  49 > which in this case is just wrong.\r
  50 \r
  51 Just this morning I sent a mail to the notmuch list, which was a reply,\r
  52 (and legitimately so), but also potentially of interest to everyone on\r
  53 the list, (since it was regarding a bug fix unrelated to the original\r
  54 topic of the thread I was replying to).\r
  55 \r
  56 So I was stuck on whether I should break the thread or not, (at the\r
  57 sending end). I guess I could have just sent a quick "this is pushed"\r
  58 reply, and independently composed a separate message telling people\r
  59 about the fix.\r
  60 \r
  61 I ended up keeping the threading intact in that case, (which I think is\r
  62 right). But maybe what we really want here is for notmuch to just\r
  63 provide a bit more indication about subject changes (say, at the search\r
  64 view). For example, I could imagine each subject change getting its own\r
  65 line in the search view, (perhaps initially hidden with a button to\r
  66 expand them). Obviously this would have to ignore trivial changes like\r
  67 adding a "Re:" or a "[LISTNAME]" prefix.\r
  68 \r
  69 > Ofcourse, it's their fault, but one can't educate the entire world. Is\r
  70 > there anything like mutt has, to break a thread at the current message?\r
  71 \r
  72 Not now. It would be a pretty trivial operation at the library level,\r
  73 (just telling the library to generate a new random thread ID for a\r
  74 particular message---and then to also recompute thread IDs for\r
  75 descendant messages).\r
  76 \r
  77 But I still have a hard time justifying user operations to manipulate\r
  78 threading. The whole point of threading is to make it faster to process\r
  79 and read messages. But manual operations like joining and splitting\r
  80 threads seem like the user just doing more work, and that *after* having\r
  81 read the messages. So that seems mostly backwards to me.\r
  82 \r
  83 -Carl\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 iD8DBQFLIWhl6JDdNq8qSWgRAmN/AKCBLbgl8yAIhoAP/bbjDHjehiTmmACfdHZs\r
  92 WVCVyrEWNNOkueGk7ysgHaM=\r
  93 =loNI\r
  94 -----END PGP SIGNATURE-----\r
  95 --=-=-=--\r