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 E55D7429E54
\r
6 for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 17:12:39 -0800 (PST)
\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 ldqZJ3yDRSDe for <notmuch@notmuchmail.org>;
\r
17 Sun, 22 Jan 2012 17:12:39 -0800 (PST)
\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 1DD1D429E40
\r
22 for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 17:12:39 -0800 (PST)
\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 1Rp8SX-0007vG-On; Mon, 23 Jan 2012 01:12:34 +0000
\r
27 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]
\r
29 by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)
\r
30 (envelope-from <m.walters@qmul.ac.uk>)
\r
31 id 1Rp8SW-0002Ao-WB; Mon, 23 Jan 2012 01:12:33 +0000
\r
32 From: Mark Walters <markwalters1009@gmail.com>
\r
33 To: Austin Clements <amdragon@MIT.EDU>
\r
34 Subject: Re: [PATCH] Automatically exclude tags in notmuch-show
\r
35 In-Reply-To: <20120122181609.GQ16740@mit.edu>
\r
36 References: <874nvric7c.fsf@qmul.ac.uk>
\r
37 <1327010583-23954-1-git-send-email-markwalters1009@gmail.com>
\r
38 <20120119225910.GT16740@mit.edu> <871uqvgrnm.fsf@qmul.ac.uk>
\r
39 <20120120171801.GA16740@mit.edu> <20120122181609.GQ16740@mit.edu>
\r
40 User-Agent: Notmuch/0.11+99~g7f60f7e (http://notmuchmail.org) Emacs/23.2.1
\r
42 Date: Mon, 23 Jan 2012 01:13:29 +0000
\r
43 Message-ID: <87zkdfgr0m.fsf@qmul.ac.uk>
\r
45 Content-Type: text/plain; charset=us-ascii
\r
46 X-Sender-Host-Address: 94.192.233.223
\r
47 X-QM-SPAM-Info: Sender has good ham record. :)
\r
48 X-QM-Body-MD5: e3f08bc77c2e3cd93e362b5e36ac0357 (of first 20000 bytes)
\r
49 X-SpamAssassin-Score: -1.8
\r
50 X-SpamAssassin-SpamBar: -
\r
51 X-SpamAssassin-Report: The QM spam filters have analysed this message to
\r
53 spam. We require at least 5.0 points to mark a message as spam.
\r
54 This message scored -1.8 points.
\r
55 Summary of the scoring:
\r
56 * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,
\r
58 * [138.37.6.40 listed in list.dnswl.org]
\r
59 * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
\r
60 provider * (markwalters1009[at]gmail.com)
\r
61 * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
\r
63 * 0.5 AWL AWL: From: address is in the auto white-list
\r
64 X-QM-Scan-Virus: ClamAV says the message is clean
\r
65 Cc: notmuch@notmuchmail.org
\r
66 X-BeenThere: notmuch@notmuchmail.org
\r
67 X-Mailman-Version: 2.1.13
\r
69 List-Id: "Use and development of the notmuch mail system."
\r
70 <notmuch.notmuchmail.org>
\r
71 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
72 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
73 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
74 List-Post: <mailto:notmuch@notmuchmail.org>
\r
75 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
76 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
77 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
78 X-List-Received-Date: Mon, 23 Jan 2012 01:12:40 -0000
\r
80 On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
\r
81 > Quoth myself on Jan 20 at 12:18 pm:
\r
82 > > Quoth Mark Walters on Jan 20 at 12:10 am:
\r
84 > > > Ok Having said this is trivial I have found a problem. What should
\r
85 > > > notmuch do if you do something like
\r
87 > > > notmuch show id:<some-id>
\r
88 > > > and that message is marked with a deleted tag? To be consistent with the
\r
89 > > > other cases (where a deleted message is in a matched thread) we might
\r
90 > > > want to return the message with the not-matched flag set (eg in
\r
91 > > > JSON). But my patch doesn't, as it never even sees the thread since it
\r
92 > > > doesn't match.
\r
94 > > > Looking at notmuch-show.c I think we should not apply the exclude tags
\r
95 > > > to do_show_single, but usually should apply it to do_show. One solution
\r
96 > > > which is simple and is at least close to right would be to get do_show
\r
97 > > > to return the number of threads found. If this is zero then retry the
\r
98 > > > query without the excludes (possible setting the match_flag to zero on
\r
99 > > > each message since we know it does not match)
\r
101 > > > This is not a completely correct solution as if you ask notmuch-show to
\r
102 > > > show more than one thread it might threads which only contain deleted
\r
105 > > > I can't see other good possibilities without slowing down the normal
\r
106 > > > path a lot (eg find all threads that match the original query and then
\r
107 > > > apply the argument above).
\r
109 > > > Any thoughts?
\r
113 > > Well, here's one idea. Instead of doing a single thread query in
\r
114 > > show, do a thread query without the exclusions and then a message
\r
115 > > query with the exclusions. Output all of the messages from the first
\r
116 > > query, but use the results of the second query to determine which
\r
117 > > messages are "matched". The same could be accomplished in the library
\r
118 > > somewhat more efficiently, but it's not obvious to me what the API
\r
121 > Here's a slightly crazier idea that's more library-invasive than the
\r
122 > original approach, but probably better in the long run.
\r
124 > Have notmuch_query_search_* return everything and make exclusion a
\r
125 > message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of
\r
126 > "matched" to mean "matched and not excluded" (specifically, a message
\r
127 > would have the match flag or the excluded flag or neither, but not
\r
128 > both). Search would skip threads with zero matched messages and I
\r
129 > think show would Just Work.
\r
131 > I can think of two ways to implement this. notmuch_query_search_*
\r
132 > could perform both the original query and the query with exclusions
\r
133 > and use the docid set from the second to compute the "excluded"
\r
134 > message flag. Alternatively, it could examine the tags of each
\r
135 > message directly to compute the flag. The latter is probably easier
\r
136 > to implement, but probably slower.
\r
140 I have now thought about this some more and think I understand your idea
\r
141 (and how it would work) rather better now.
\r
143 I would suggest one small change: the flags for the messages returned
\r
144 should be "independent": so a message can match the query or not, and it
\r
145 can be excluded or not, with all 4 combinations being possible. (The
\r
146 consumer of notmuch_query_search_* would extract the information it
\r
149 I have thought about some implementation ideas but I think sorting is
\r
150 going to be the deciding factor: what order should
\r
151 notmuch_query_search_* return messages/threads?
\r
153 For notmuch_query_search_messages either it returns them all together
\r
154 with the excluded messages marked, or returns all included ones, and
\r
155 then all excluded one.
\r
157 For notmuch_query_search_threads it is less clear. Currently it returns
\r
158 threads in order of first matching message. It is not clear what
\r
159 matching means now: is matching and included, or just matching? If the
\r
160 former then we will be returning some threads with no matching and
\r
161 included messages so we need to decide where to put them in the order.
\r
163 If we sort in both cases just on matching then we have the same
\r
164 output/sort as notmuch pre-excluded flags, just the frontends
\r
165 notmuch-search/show can decide to omit some lines/results. Note that
\r
166 after omitting "excluded" lines the thread sort would be different from
\r
167 the current notmuch-with-excluded implementation.
\r
169 Whereas if we sort based on matching and included, we keep the current
\r
170 sort order with some stuff appended.
\r
172 As regards implementation I think notmuch_query_search_messages is the
\r
173 crucial place: once that returns one of its two orders the rest sort of
\r
174 takes care of itself.
\r
projects / notmuch-archives.git / blob