15/91430e21379542f47cc7e63dd782dcd27071f8

   1 Return-Path: <jani@nikula.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 C8917431FAF\r
   6         for <notmuch@notmuchmail.org>; Mon, 28 Jan 2013 07:13:33 -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.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 wCkzBoGJO-Dn for <notmuch@notmuchmail.org>;\r
  16         Mon, 28 Jan 2013 07:13:33 -0800 (PST)\r
  17 Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com\r
  18         [209.85.214.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id C3DD8431FAE\r
  21         for <notmuch@notmuchmail.org>; Mon, 28 Jan 2013 07:13:32 -0800 (PST)\r
  22 Received: by mail-bk0-f44.google.com with SMTP id j4so1402833bkw.17\r
  23         for <notmuch@notmuchmail.org>; Mon, 28 Jan 2013 07:13:30 -0800 (PST)\r
  24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  25         d=google.com; s=20120113;\r
  26         h=x-received:from:to:subject:in-reply-to:references:user-agent:date\r
  27         :message-id:mime-version:content-type:x-gm-message-state;\r
  28         bh=Zd8xAeNCq1DsVm+H8MPBCA1HQCjWmF9AF33ZVEdpQbk=;\r
  29         b=jBb9oQLYjn8hI4xYSrh0ZtYrg0CuICYpkryiPTBcxqJsyjkk2RjO0bT7CFdlvRcT9P\r
  30         niqnQyz+7zpJR91cxnhK+oVC98zPMHwSbt99NBqDT9hYmsVD744zGYGK5lnvFgM2JJ4n\r
  31         KBRYRzHL+QeBWSzhp6KAr4VxY5foGX+5csSajBK5paxljETN8AWI2EaR7yCJb3z6NYPt\r
  32         VAxReVDiwZW3qeTSfkyrLbaMMcusyTYJfZ/8fvjkIpwJm+8Z7rtCS+V+jCP3FW80raZb\r
  33         fUDXOVrmWKOvUKfq6qjvKmepcafXOlGny/SgBsBhRedfSXjKR38UWgSmPCIOJuVCTxjs\r
  34         mYKw==\r
  35 X-Received: by 10.204.13.25 with SMTP id z25mr505432bkz.114.1359386008694;\r
  36         Mon, 28 Jan 2013 07:13:28 -0800 (PST)\r
  37 Received: from localhost ([2001:4b98:dc0:43:216:3eff:fe1b:25f3])\r
  38         by mx.google.com with ESMTPS id fs20sm4075475bkc.8.2013.01.28.07.13.26\r
  39         (version=TLSv1.1 cipher=RC4-SHA bits=128/128);\r
  40         Mon, 28 Jan 2013 07:13:27 -0800 (PST)\r
  41 From: Jani Nikula <jani@nikula.org>\r
  42 To: Robert Mast <beheerder@tekenbeetziekten.nl>, notmuch@notmuchmail.org\r
  43 Subject: Re: Reply all - issue\r
  44 In-Reply-To: <000001cdfcd9$82500f00$86f02d00$@nl>\r
  45 References: <000001cdfcd9$82500f00$86f02d00$@nl>\r
  46 User-Agent: Notmuch/0.14+259~gdee88db (http://notmuchmail.org) Emacs/23.2.1\r
  47         (x86_64-pc-linux-gnu)\r
  48 Date: Mon, 28 Jan 2013 16:13:19 +0100\r
  49 Message-ID: <87wquxjq7k.fsf@nikula.org>\r
  50 MIME-Version: 1.0\r
  51 Content-Type: text/plain; charset=us-ascii\r
  52 X-Gm-Message-State:\r
  53  ALoCoQnuswafvHmLQkGJxLiy77Ick30gH97f9KxVgnporeWA6hQINQ1scazh6XbO3IW0ApuHXOWD\r
  54 X-BeenThere: notmuch@notmuchmail.org\r
  55 X-Mailman-Version: 2.1.13\r
  56 Precedence: list\r
  57 List-Id: "Use and development of the notmuch mail system."\r
  58         <notmuch.notmuchmail.org>\r
  59 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  60         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  61 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  62 List-Post: <mailto:notmuch@notmuchmail.org>\r
  63 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  64 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  65         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  66 X-List-Received-Date: Mon, 28 Jan 2013 15:13:33 -0000\r
  67 \r
  68 On Sun, 27 Jan 2013, Robert Mast <beheerder@tekenbeetziekten.nl> wrote:\r
  69 > Last week I studied many Windows-Mail User Agents with the conversation\r
  70 > threading feature.\r
  71 >\r
  72 > None of them (SUP, mutt-kz(notmuch), Outlook 2010, Thunderbird with\r
  73 > conversation thread plug in, Postbox, Evolution) could cope with the\r
  74 > following case:\r
  75 \r
  76 Apparently all of them obey the RFC 2822 References: and In-Reply-To:\r
  77 headers for threading, and have no additional heuristics. I think it's a\r
  78 good thing, but YMMV. I think mutt supports manual breaking and joining\r
  79 of threads. The gmail web interface, OTOH, automatically breaks threads\r
  80 on Subject: changes too [1].\r
  81 \r
  82 > In our e-mail-discussions people often choose 'reply-all' to construct a new\r
  83 > message with the same reciepients.\r
  84 >\r
  85 > They clear the body and the subject, but the hidden References: and\r
  86 > In-reply-To: stay and should be cleared as well.\r
  87 >\r
  88 > Result is that this new subject drowns in an old\r
  89 > conversation-thread-drilldown and this unpredictable behavior makes\r
  90 > conversation threading useless.\r
  91 \r
  92 The term you're looking for is thread hijacking. One could argue the\r
  93 problem lies in the sender, not the recipient, and therefore should be\r
  94 fixed in the sender end.\r
  95 \r
  96 > I think of a fix that indexes the first dates of (stripped) subject-changes\r
  97 > within threads, and with each first (stripped) subject change check the body\r
  98 > on quotes of previous messages. If there is no quote to referenced mails\r
  99 > then drop the reference and assign a new thread_id_ to the (stripped)\r
 100 > subject.\r
 101 \r
 102 Doing something like this would break threading for emailed patch series\r
 103 [2], a very common practice in the open source world, including notmuch\r
 104 development [3]. Indeed, the way gmail breaks patch threads, but then\r
 105 joins different versions of the same patch email into new threads, is\r
 106 very annoying IMO.\r
 107 \r
 108 Also note that whatever you do, it should work the same way regardless\r
 109 of the order in which messages the thread are indexed. Regenerating the\r
 110 database should always end up in the same thread structure.\r
 111 \r
 112 > After two days of studying I think the best place with the least\r
 113 > interference with existing code is between 'notmuch new' and starting the\r
 114 > MUA. Then the threads are in place in XAPIAN, and new thread_id_'s can be\r
 115 > inserted.\r
 116 \r
 117 The place you're looking for is probably\r
 118 _notmuch_database_link_message() in lib/database.cc.\r
 119 \r
 120 Patches, as they say, are welcome, but I believe for upstream notmuch\r
 121 inclusion you'd need to address the issues I pointed out above.\r
 122 \r
 123 HTH,\r
 124 Jani.\r
 125 \r
 126 \r
 127 [1] http://support.google.com/mail/bin/answer.py?hl=en&answer=5900\r
 128 \r
 129 [2] http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Public-Large-Project\r
 130 \r
 131 [3] http://notmuchmail.org/pipermail/notmuch/2013/thread.html\r