From ba4affab0f4d2ace2d6a02b88fbeb0b6749620e2 Mon Sep 17 00:00:00 2001 From: Jesse Rosenthal Date: Thu, 30 Oct 2014 09:39:39 +2000 Subject: [PATCH] Re: [PATCH] Avoid empty thread names if possible. --- 92/5aa7966e34690e29b0468d2e1c4db1a2ed5df7 | 119 ++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 92/5aa7966e34690e29b0468d2e1c4db1a2ed5df7 diff --git a/92/5aa7966e34690e29b0468d2e1c4db1a2ed5df7 b/92/5aa7966e34690e29b0468d2e1c4db1a2ed5df7 new file mode 100644 index 000000000..722b79919 --- /dev/null +++ b/92/5aa7966e34690e29b0468d2e1c4db1a2ed5df7 @@ -0,0 +1,119 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 883E2431FC2 + for ; Wed, 29 Oct 2014 06:39:47 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id prFwVLxBB8kN for ; + Wed, 29 Oct 2014 06:39:42 -0700 (PDT) +Received: from smtpauth.johnshopkins.edu (smtpauth.johnshopkins.edu + [128.220.229.157]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 766DB431FB6 + for ; Wed, 29 Oct 2014 06:39:42 -0700 (PDT) +X-IronPort-AV: E=Sophos;i="5.04,810,1406606400"; d="scan'208";a="541580579" +Received: from guppy.hwcampus.jhu.edu (HELO localhost) ([10.161.32.234]) + by IPMTW2.johnshopkins.edu with ESMTP/TLS/AES128-SHA; + 29 Oct 2014 09:39:40 -0400 +From: Jesse Rosenthal +To: Mark Walters , notmuch@notmuchmail.org +Subject: Re: [PATCH] Avoid empty thread names if possible. +In-Reply-To: <87tx2nuvec.fsf@qmul.ac.uk> +References: <87oatnakqy.fsf@jhu.edu> <87tx2nuvec.fsf@qmul.ac.uk> +User-Agent: Notmuch/0.18.2+155~gafa8535 (http://notmuchmail.org) Emacs/24.4.1 + (i686-pc-linux-gnu) +Date: Wed, 29 Oct 2014 09:39:39 -0400 +Message-ID: <87ppdb9eqs.fsf@jhu.edu> +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Wed, 29 Oct 2014 13:39:47 -0000 + +[I'm not sure why the below reply did not go to the list. Later replies +did, so I assume there must have been so problem in the sending. Mark, +apologies if you get this twice.] + +Hi, + +Thanks for taking a look at this. + +Mark Walters writes: +> I approve of the change in the output but I am unsure about the +> implementation. It would be nice to have a clear rule about which +> subject is taken. Eg: +> +> if sort is oldest first then it is the subject of the oldest +> matching message with a non-empty subject. Similarly if sort +> is newest first. + +The rule is actually in a four-year-old commit message (4971b85c4), in +almost exactly the same words you used: + + ...name threads based on (a) matches for the query, and (b) the + search order. If the search order is oldest-first (as in the default + inbox) it chooses the oldest matching message as the subject. If the + search order is newest-first it chooses the newest one. + + Reply prefixes ("Re: ", "Aw: ", "Sv: ", "Vs: ") are ignored + (case-insensitively) so a Re: won't change the subject. + +So we would, essentially, just need to add "non-empty" to this +phrasing. Where would be the right place to put it? Commit message? +NEWS? `search` man page? + +> Also, it would be nice if the implementation did not rely on what order +> we call _thread_add_matched_message on the matching messages in the +> thread. I think in some ways we already rely on the order (for the order +> of the author list), but if you want to rely on the order here I think +> it at least deserves a comment. + +That would require a rethinking, I think, of naming -- since it's +traditionally worked in terms of renaming. When a better option comes, +we throw out the old one. So order is pretty essential. (Not saying +that's the best way, just pointing out that it's the way it's been done +since Carl's initial alpha release.) + +> So looking at the above I think the oldest first gives the subject in +> my suggestion above (since the messages are supplied in oldest first +[ 4 more citation lines. Click/Enter to show. ] +> order). But newest first may not: indeed if the subject starts out as +> something and becomes empty then this will set the subject empty and +> then leave it + +> (Note b_thread_set_subject_from_message calls notmuch_message_get_header +> which returns an empty string "" if the subject line is empty or not +> present). + +Hmmm... I was looking at the following line in +_thread_set_subject_from_message: + + subject = notmuch_message_get_header (message, "subject"); + if (! subject) + return; + +So, I don't think we ever actually change a content-ful string subject +to an empty one, as you describe above? If there's a non-empty string +there, and we get an empty subject, we leave the non-empty string in +place, right? + +Best, +Jesse -- 2.26.2