--- /dev/null
+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 883E2431FC2\r
+ for <notmuch@notmuchmail.org>; Wed, 29 Oct 2014 06:39:47 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+ 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 prFwVLxBB8kN for <notmuch@notmuchmail.org>;\r
+ Wed, 29 Oct 2014 06:39:42 -0700 (PDT)\r
+Received: from smtpauth.johnshopkins.edu (smtpauth.johnshopkins.edu\r
+ [128.220.229.157]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 766DB431FB6\r
+ for <notmuch@notmuchmail.org>; Wed, 29 Oct 2014 06:39:42 -0700 (PDT)\r
+X-IronPort-AV: E=Sophos;i="5.04,810,1406606400"; d="scan'208";a="541580579"\r
+Received: from guppy.hwcampus.jhu.edu (HELO localhost) ([10.161.32.234])\r
+ by IPMTW2.johnshopkins.edu with ESMTP/TLS/AES128-SHA;\r
+ 29 Oct 2014 09:39:40 -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:39:39 -0400\r
+Message-ID: <87ppdb9eqs.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 13:39:47 -0000\r
+\r
+[I'm not sure why the below reply did not go to the list. Later replies\r
+did, so I assume there must have been so problem in the sending. Mark,\r
+apologies if you get this twice.]\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
+[ 4 more citation lines. Click/Enter to show. ]\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
projects / notmuch-archives.git / commitdiff