Re: [PATCH] Avoid empty thread names if possible.

diff --git a/c4/45b86170904c3739f61efa480e220b4746b91d b/c4/45b86170904c3739f61efa480e220b4746b91d
new file mode 100644 (file)
index 0000000..6f2be35
--- /dev/null
+++ b/c4/45b86170904c3739f61efa480e220b4746b91d
@@ -0,0 +1,115 @@
+Return-Path: <prvs=372b3579b=jrosenthal@jhu.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 4FCC3431FC7\r
+       for <notmuch@notmuchmail.org>; Wed, 29 Oct 2014 07:07:36 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.3\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id ImRQiZglXoRj for <notmuch@notmuchmail.org>;\r
+       Wed, 29 Oct 2014 07:07:31 -0700 (PDT)\r
+Received: from IPMTW1.johnshopkins.edu (ipmtw1.johnshopkins.edu\r
+       [128.220.229.140]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 6D7F5431FB6\r
+       for <notmuch@notmuchmail.org>; Wed, 29 Oct 2014 07:07:31 -0700 (PDT)\r
+X-IronPort-AV: E=Sophos;i="5.04,809,1406606400"; d="scan'208";a="15416851"\r
+Received: from guppy.hwcampus.jhu.edu (HELO localhost) ([10.161.32.234])\r
+       by IPMTW1.johnshopkins.edu with ESMTP/TLS/AES128-SHA;\r
+       29 Oct 2014 09:05:25 -0400\r
+From: Jesse Rosenthal <jrosenthal@jhu.edu>\r
+To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH] Avoid empty thread names if possible.\r
+In-Reply-To: <87tx2nuvec.fsf@qmul.ac.uk>\r
+References: <87oatnakqy.fsf@jhu.edu> <87tx2nuvec.fsf@qmul.ac.uk>\r
+User-Agent: Notmuch/0.18.2+155~gafa8535 (http://notmuchmail.org) Emacs/24.4.1\r
+       (i686-pc-linux-gnu)\r
+Date: Wed, 29 Oct 2014 09:05:24 -0400\r
+Message-ID: <87d29b2fhn.fsf@jhu.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 29 Oct 2014 14:07:36 -0000\r
+\r
+Hi,\r
+\r
+Thanks for taking a look at this.\r
+\r
+Mark Walters <markwalters1009@gmail.com> writes:\r
+> I approve of the change in the output but I am unsure about the\r
+> implementation. It would be nice to have a clear rule about which\r
+> subject is taken. Eg: \r
+>\r
+>         if sort is oldest first then it is the subject of the oldest\r
+>         matching message with a non-empty subject. Similarly if sort\r
+>         is newest first.\r
+\r
+The rule is actually in a four-year-old commit message (4971b85c4), in\r
+almost exactly the same words you used:\r
+\r
+    ...name threads based on (a) matches for the query, and (b) the\r
+    search order. If the search order is oldest-first (as in the default\r
+    inbox) it chooses the oldest matching message as the subject. If the\r
+    search order is newest-first it chooses the newest one.\r
+    \r
+    Reply prefixes ("Re: ", "Aw: ", "Sv: ", "Vs: ") are ignored\r
+    (case-insensitively) so a Re: won't change the subject.\r
+\r
+So we would, essentially, just need to add "non-empty" to this\r
+phrasing. Where would be the right place to put it? Commit message?\r
+NEWS? `search` man page?\r
+\r
+> Also, it would be nice if the implementation did not rely on what order\r
+> we call _thread_add_matched_message on the matching messages in the\r
+> thread. I think in some ways we already rely on the order (for the order\r
+> of the author list), but if you want to rely on the order here I think\r
+> it at least deserves a comment.\r
+\r
+That would require a rethinking, I think, of naming -- since it's\r
+traditionally worked in terms of renaming. When a better option comes,\r
+we throw out the old one. So order is pretty essential. (Not saying\r
+that's the best way, just pointing out that it's the way it's been done\r
+since Carl's initial alpha release.)\r
+\r
+> So looking at the above I think the oldest first gives the subject in\r
+> my suggestion above (since the messages are supplied in oldest first\r
+> order). But newest first may not: indeed if the subject starts out as\r
+> something and becomes empty then this will set the subject empty and\r
+> then leave it\r
+\r
+> (Note b_thread_set_subject_from_message calls notmuch_message_get_header\r
+> which returns an empty string "" if the subject line is empty or not\r
+> present).\r
+\r
+Hmmm... I was looking at the following line in\r
+_thread_set_subject_from_message:\r
+\r
+    subject = notmuch_message_get_header (message, "subject");\r
+    if (! subject)\r
+       return;\r
+\r
+So, I don't think we ever actually change a content-ful string subject\r
+to an empty one, as you describe above? If there's a non-empty string\r
+there, and we get an empty subject, we leave the non-empty string in\r
+place, right?\r
+\r
+Best,\r
+Jesse\r
+\r