1 Return-Path: <sojkam1@fel.cvut.cz>
\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 5812C4196F2
\r
6 for <notmuch@notmuchmail.org>; Mon, 12 Apr 2010 08:11:29 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
\r
12 tests=[BAYES_00=-1.9] autolearn=ham
\r
13 Received: from olra.theworths.org ([127.0.0.1])
\r
14 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id PUWpYdEKJDdY for <notmuch@notmuchmail.org>;
\r
16 Mon, 12 Apr 2010 08:11:28 -0700 (PDT)
\r
17 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])
\r
18 by olra.theworths.org (Postfix) with ESMTP id 06375431FC1
\r
19 for <notmuch@notmuchmail.org>; Mon, 12 Apr 2010 08:11:27 -0700 (PDT)
\r
20 Received: from localhost (unknown [192.168.200.4])
\r
21 by max.feld.cvut.cz (Postfix) with ESMTP id 5E36C19F331D;
\r
22 Mon, 12 Apr 2010 17:11:27 +0200 (CEST)
\r
23 X-Virus-Scanned: IMAP AMAVIS
\r
24 Received: from max.feld.cvut.cz ([192.168.200.1])
\r
25 by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,
\r
27 with ESMTP id iONcZpDYTWR0; Mon, 12 Apr 2010 17:11:26 +0200 (CEST)
\r
28 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])
\r
29 by max.feld.cvut.cz (Postfix) with ESMTP id EF6C119F3347;
\r
30 Mon, 12 Apr 2010 17:11:25 +0200 (CEST)
\r
31 Received: from steelpick.2x.cz (k335-30.felk.cvut.cz [147.32.86.30])
\r
32 (Authenticated sender: sojkam1)
\r
33 by imap.feld.cvut.cz (Postfix) with ESMTPSA id EA68A15C062;
\r
34 Mon, 12 Apr 2010 17:11:24 +0200 (CEST)
\r
35 Received: from wsh by steelpick.2x.cz with local (Exim 4.71)
\r
36 (envelope-from <sojkam1@fel.cvut.cz>)
\r
37 id 1O1LIK-0008Tb-LJ; Mon, 12 Apr 2010 17:11:24 +0200
\r
38 From: Michal Sojka <sojkam1@fel.cvut.cz>
\r
39 To: Jameson Rollins <jrollins@finestructure.net>,
\r
40 Sebastian Spaeth <Sebastian@SSpaeth.de>, Anthony Towns <aj@erisian.com.au>,
\r
41 notmuch <notmuch@notmuchmail.org>
\r
42 Subject: Re: [PATCH] notmuch new --new-tags=tags...
\r
43 In-Reply-To: <87y6gseval.fsf@servo.finestructure.net>
\r
44 References: <n2x87b3a4191004100803z9d4c4c2bp52f5cf0d7b712362@mail.gmail.com>
\r
45 <871velp0be.fsf@SSpaeth.de>
\r
46 <87y6gseval.fsf@servo.finestructure.net>
\r
47 Date: Mon, 12 Apr 2010 17:11:24 +0200
\r
48 Message-ID: <87633wbt9f.fsf@steelpick.2x.cz>
\r
50 Content-Type: text/plain; charset=us-ascii
\r
51 X-BeenThere: notmuch@notmuchmail.org
\r
52 X-Mailman-Version: 2.1.13
\r
54 List-Id: "Use and development of the notmuch mail system."
\r
55 <notmuch.notmuchmail.org>
\r
56 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
57 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
58 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
59 List-Post: <mailto:notmuch@notmuchmail.org>
\r
60 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
61 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
62 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
63 X-List-Received-Date: Mon, 12 Apr 2010 15:11:29 -0000
\r
65 On Mon, 12 Apr 2010, Jameson Rollins wrote:
\r
66 > On Mon, 12 Apr 2010 10:00:37 +0200, "Sebastian Spaeth" <Sebastian@SSpaeth.de> wrote:
\r
67 > > On 2010-04-10, Anthony Towns wrote:
\r
68 > > > The attached patch makes "notmuch new --new-tags=unread,new" set the
\r
69 > > > "unread" and "new" tags on any new mail it finds rather than "unread"
\r
70 > > > and "inbox". Or whatever other tags you happen to specify.
\r
72 > > Thanks for the patch. I can't comment on the code quality, but rather
\r
73 > > than having to specify the set of new tags on the command line every
\r
74 > > time, I think it would make more sense to put them in the notmuch config
\r
75 > > file as this patch does:
\r
76 > > id:1268432006-24333-2-git-send-email-bgamari.foss@gmail.com
\r
78 > I was thinking about this, and it seems to me that we really need is a
\r
79 > way to just specify which tags should be applied to new messages based
\r
80 > on search terms. It's becoming pretty clear that most people are doing
\r
81 > some sort of post-notmuch-new tag processing to modify the tags of new
\r
82 > messages to suite their needs. Why not just integrate this directly
\r
83 > into the notmuch-new processing itself? It seems like if this was
\r
84 > integrated into notmuch-new directly, the entire processing of new
\r
85 > messages could be sped up considerably, so that one wouldn't have to
\r
86 > call multiple notmuch-new processes in succession.
\r
88 In my mailstore abstraction patches, I suppose that tags for new
\r
89 messages are derived in some way from mailstore. The idea is, that once
\r
90 we have a mail store which can store tags (e.g. git-based mails store),
\r
91 the tags will be assigned on delivery by tools like procmail and notmuch
\r
92 will only index that tags for faster searching. The problem is the it
\r
93 will take some time to implement all of this and we want this
\r
97 > I'm not sure exactly what the best way to handle it would be, but I can
\r
98 > imagine something like this:
\r
101 > +sent -new -- from:jrollins@finestructure.net
\r
102 > +drafts -new -- folder:draft
\r
103 > +notmuch -- from:notmuch@notmuchmail.org
\r
104 > +unread +inbox -new -- tag:new
\r
106 > These are all just commands for "notmuch tag" that would be run on all
\r
107 > the new messages as they're processed. Each new message would be given
\r
108 > "new" tag by default, and then the new tag commands would be run. So it
\r
109 > would be the equivalent of running the following commands:
\r
111 > notmuch new --new-tags=new
\r
112 > notmuch tag +sent -new -- from:jrollins@finestructure.net
\r
113 > notmuch tag +drafts -new -- folder:draft
\r
114 > notmuch tag +notmuch -- from:notmuch@notmuchmail.org
\r
115 > notmuch tag +unread +inbox -- tag:new
\r
117 The problem I see with this approach is, that all notmuch searches are
\r
118 build around Xapian. A simple implementation of the above would mean
\r
119 that whenever you add a new message to the database, you would need to
\r
120 execute a Xapian query to see if the new message matches your rule or
\r
121 not. This would be, of course, very expensive.
\r
123 If we do not want to use xapian for searching, we would have to
\r
124 implement all the query parsing. building and whatever in notmuch and I
\r
125 do not think it belongs there.
\r
127 I do not know much about Xapian internals, so there might be a way of
\r
128 doing this without reimplementing everything, so correct me if I'm
\r
projects / notmuch-archives.git / blob