1 Return-Path: <m.walters@qmul.ac.uk>
\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 E218C431FC2
\r
6 for <notmuch@notmuchmail.org>; Wed, 29 Oct 2014 08:15:40 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5
\r
12 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,
\r
13 NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled
\r
14 Received: from olra.theworths.org ([127.0.0.1])
\r
15 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
16 with ESMTP id 9sDaPYZ9ez9M for <notmuch@notmuchmail.org>;
\r
17 Wed, 29 Oct 2014 08:15:36 -0700 (PDT)
\r
18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])
\r
19 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id CECF8431FB6
\r
22 for <notmuch@notmuchmail.org>; Wed, 29 Oct 2014 08:15:35 -0700 (PDT)
\r
23 Received: from smtp.qmul.ac.uk ([138.37.6.40])
\r
24 by mail2.qmul.ac.uk with esmtp (Exim 4.71)
\r
25 (envelope-from <m.walters@qmul.ac.uk>)
\r
26 id 1XjUyA-0004fQ-5C; Wed, 29 Oct 2014 15:15:30 +0000
\r
27 Received: from 5751dfa2.skybroadband.com ([87.81.223.162] helo=localhost)
\r
28 by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)
\r
29 (envelope-from <m.walters@qmul.ac.uk>)
\r
30 id 1XjUy9-0006Fi-Of; Wed, 29 Oct 2014 15:15:29 +0000
\r
31 From: Mark Walters <markwalters1009@gmail.com>
\r
32 To: Jesse Rosenthal <jrosenthal@jhu.edu>, notmuch@notmuchmail.org
\r
33 Subject: Re: [PATCH] Avoid empty thread names if possible.
\r
34 In-Reply-To: <87ppdb9eqs.fsf@jhu.edu>
\r
35 References: <87oatnakqy.fsf@jhu.edu> <87tx2nuvec.fsf@qmul.ac.uk>
\r
36 <87ppdb9eqs.fsf@jhu.edu>
\r
37 User-Agent: Notmuch/0.18.1+86~gef5e66a (http://notmuchmail.org) Emacs/23.4.1
\r
38 (x86_64-pc-linux-gnu)
\r
39 Date: Wed, 29 Oct 2014 15:15:29 +0000
\r
40 Message-ID: <87tx2maovi.fsf@qmul.ac.uk>
\r
42 Content-Type: text/plain; charset=us-ascii
\r
43 X-Sender-Host-Address: 87.81.223.162
\r
44 X-QM-Geographic: According to ripencc,
\r
45 this message was delivered by a machine in Britain (UK) (GB).
\r
46 X-QM-SPAM-Info: Sender has good ham record. :)
\r
47 X-QM-Body-MD5: 95ba90fb2b3b95c06b27d3b844fe64cd (of first 20000 bytes)
\r
48 X-SpamAssassin-Score: -0.1
\r
49 X-SpamAssassin-SpamBar: /
\r
50 X-SpamAssassin-Report: The QM spam filters have analysed this message to
\r
52 spam. We require at least 5.0 points to mark a message as spam.
\r
53 This message scored -0.1 points.
\r
54 Summary of the scoring:
\r
55 * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
\r
56 provider * (markwalters1009[at]gmail.com)
\r
57 * -0.1 AWL AWL: From: address is in the auto white-list
\r
58 X-QM-Scan-Virus: ClamAV says the message is clean
\r
59 X-BeenThere: notmuch@notmuchmail.org
\r
60 X-Mailman-Version: 2.1.13
\r
62 List-Id: "Use and development of the notmuch mail system."
\r
63 <notmuch.notmuchmail.org>
\r
64 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
65 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
66 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
67 List-Post: <mailto:notmuch@notmuchmail.org>
\r
68 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
69 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
70 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
71 X-List-Received-Date: Wed, 29 Oct 2014 15:15:41 -0000
\r
76 On Wed, 29 Oct 2014, Jesse Rosenthal <jrosenthal@jhu.edu> wrote:
\r
77 > [I'm not sure why the below reply did not go to the list. Later replies
\r
78 > did, so I assume there must have been so problem in the sending. Mark,
\r
79 > apologies if you get this twice.]
\r
83 > Thanks for taking a look at this.
\r
85 > Mark Walters <markwalters1009@gmail.com> writes:
\r
86 >> I approve of the change in the output but I am unsure about the
\r
87 >> implementation. It would be nice to have a clear rule about which
\r
88 >> subject is taken. Eg:
\r
90 >> if sort is oldest first then it is the subject of the oldest
\r
91 >> matching message with a non-empty subject. Similarly if sort
\r
94 > The rule is actually in a four-year-old commit message (4971b85c4), in
\r
95 > almost exactly the same words you used:
\r
97 > ...name threads based on (a) matches for the query, and (b) the
\r
98 > search order. If the search order is oldest-first (as in the default
\r
99 > inbox) it chooses the oldest matching message as the subject. If the
\r
100 > search order is newest-first it chooses the newest one.
\r
102 > Reply prefixes ("Re: ", "Aw: ", "Sv: ", "Vs: ") are ignored
\r
103 > (case-insensitively) so a Re: won't change the subject.
\r
105 > So we would, essentially, just need to add "non-empty" to this
\r
106 > phrasing. Where would be the right place to put it? Commit message?
\r
107 > NEWS? `search` man page?
\r
109 First I just wanted to check that I knew exactly what behaviour was
\r
110 intended. Having the new rule in the commit message might well be
\r
113 >> Also, it would be nice if the implementation did not rely on what order
\r
114 >> we call _thread_add_matched_message on the matching messages in the
\r
115 >> thread. I think in some ways we already rely on the order (for the order
\r
116 >> of the author list), but if you want to rely on the order here I think
\r
117 >> it at least deserves a comment.
\r
119 > That would require a rethinking, I think, of naming -- since it's
\r
120 > traditionally worked in terms of renaming. When a better option comes,
\r
121 > we throw out the old one. So order is pretty essential. (Not saying
\r
122 > that's the best way, just pointing out that it's the way it's been done
\r
123 > since Carl's initial alpha release.)
\r
125 I think that the current code does not depend on the order the messages
\r
126 are given to _thread_add_matched_message: regardless of the order the
\r
127 thread will get the subject of the oldest matching message (in
\r
130 In contrast your code will give different subjects depending in the
\r
131 order the messages are fed to _thread_add_matched_message.
\r
133 >> So looking at the above I think the oldest first gives the subject in
\r
134 >> my suggestion above (since the messages are supplied in oldest first
\r
135 >> order). But newest first may not: indeed if the subject starts out as
\r
136 >> something and becomes empty then this will set the subject empty and
\r
139 >> (Note b_thread_set_subject_from_message calls notmuch_message_get_header
\r
140 >> which returns an empty string "" if the subject line is empty or not
\r
143 > Hmmm... I was looking at the following line in
\r
144 > _thread_set_subject_from_message:
\r
146 > subject = notmuch_message_get_header (message, "subject");
\r
150 but subject="" is not null; subject is only null if
\r
151 notmuch_message_get_header throws an error. See the documentation for
\r
152 notmuch_message_get_header.
\r
161 > So, I don't think we ever actually change a content-ful string subject
\r
162 > to an empty one, as you describe above? If there's a non-empty string
\r
163 > there, and we get an empty subject, we leave the non-empty string in
\r