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 A4BF340DBC6
\r
6 for <notmuch@notmuchmail.org>; Wed, 10 Nov 2010 02:26:57 -0800 (PST)
\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=unavailable
\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 1NEzFkvExjSR for <notmuch@notmuchmail.org>;
\r
16 Wed, 10 Nov 2010 02:26:45 -0800 (PST)
\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 716A940DBE4
\r
19 for <notmuch@notmuchmail.org>; Wed, 10 Nov 2010 02:26:45 -0800 (PST)
\r
20 Received: from localhost (unknown [192.168.200.4])
\r
21 by max.feld.cvut.cz (Postfix) with ESMTP id DBD2519F331A;
\r
22 Wed, 10 Nov 2010 11:26:43 +0100 (CET)
\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 31XZSaK0mOWq; Wed, 10 Nov 2010 11:26:41 +0100 (CET)
\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 A025F19F331D;
\r
30 Wed, 10 Nov 2010 11:26:41 +0100 (CET)
\r
31 Received: from steelpick.2x.cz (note-sojka.felk.cvut.cz [147.32.86.30])
\r
32 (Authenticated sender: sojkam1)
\r
33 by imap.feld.cvut.cz (Postfix) with ESMTPSA id BBE6BFA004;
\r
34 Wed, 10 Nov 2010 11:26:40 +0100 (CET)
\r
35 Received: from wsh by steelpick.2x.cz with local (Exim 4.72)
\r
36 (envelope-from <sojkam1@fel.cvut.cz>)
\r
37 id 1PG7t2-0003vB-7K; Wed, 10 Nov 2010 11:26:40 +0100
\r
38 From: Michal Sojka <sojkam1@fel.cvut.cz>
\r
39 To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
\r
40 Subject: Re: [PATCH v4 0/4] Maildir synchronization
\r
41 In-Reply-To: <87lj52knbp.fsf@yoom.home.cworth.org>
\r
42 References: <87tyk3vpxd.fsf@wsheee.2x.cz>
\r
43 <1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>
\r
44 <877hgsrjau.fsf@yoom.home.cworth.org> <87d3qhq527.fsf@resox.2x.cz>
\r
45 <874obrmww9.fsf@yoom.home.cworth.org>
\r
46 <87iq066cbd.fsf@steelpick.2x.cz>
\r
47 <87oc9ykzae.fsf@yoom.home.cworth.org>
\r
48 <877hgm2hjg.fsf@steelpick.2x.cz>
\r
49 <87lj52knbp.fsf@yoom.home.cworth.org>
\r
50 User-Agent: Notmuch/0.4-30-ga01dbf0 (http://notmuchmail.org) Emacs/23.2.1
\r
51 (x86_64-pc-linux-gnu)
\r
52 Date: Wed, 10 Nov 2010 11:26:40 +0100
\r
53 Message-ID: <874obp325b.fsf@steelpick.2x.cz>
\r
55 Content-Type: text/plain; charset=us-ascii
\r
56 X-BeenThere: notmuch@notmuchmail.org
\r
57 X-Mailman-Version: 2.1.13
\r
59 List-Id: "Use and development of the notmuch mail system."
\r
60 <notmuch.notmuchmail.org>
\r
61 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
62 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
63 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
64 List-Post: <mailto:notmuch@notmuchmail.org>
\r
65 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
66 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
67 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
68 X-List-Received-Date: Wed, 10 Nov 2010 10:26:57 -0000
\r
70 On Wed, 10 Nov 2010, Carl Worth wrote:
\r
71 > > This only fails if the message is in */new and there is no */cur.
\r
73 > Right. I think that's a little too severe.
\r
75 > > I do not know if MH format has something special or it is just plain
\r
76 > > files in plain directories. If the latter, the synchronzation should
\r
77 > > work unless one of the directories is named 'new'.
\r
79 > The MH format is plain files in plain directories.
\r
81 > But in this case, I would contend that we don't _want_ the
\r
82 > synchronization to work. The files shouldn't be getting renamed at all
\r
83 > unless we are dealing with maildir.
\r
85 Yes, I think this could be easily implemented.
\r
87 > Neither maildir nor mh give us anything extremely reliable that we can
\r
88 > use to unambiguously distinguish between them. But I think a heuristic
\r
91 > if "cur" and "new" sub-directories exist:
\r
92 > then this directory is maildir;
\r
94 > And only when this heuristic passes should we be fiddling with filenames
\r
95 > in maildir-specified ways.
\r
99 > Meanwhile, I ran into one problem with my proposal. We can't use
\r
100 > notmuch_message_sync_with_maildir_flags since notmuch_message_sync is an
\r
101 > internal interface. The corresponding public interface actually consists
\r
102 > of three or four different functions (notmuch_message_add_tag,
\r
103 > notmuch_message_remove_tag, and notmuch_message_freeze/thaw). I think it
\r
104 > would be quite crazy to add _with_maildir_flags variants of all of
\r
107 > So maybe we will need a new function for the purpose of synchronizing
\r
108 > the current tags of a message to a maildir filename. So that would be,
\r
109 > perhaps, notmuch_message_tags_to_maildir_flags or so?
\r
111 This sounds good and allows us to get rid of
\r
112 NOTMUCH_MESSAGE_FLAG_TAGS_INVALID.
\r
114 > Finally, I'm also a bit unsettled about the handling of the "S"
\r
115 > flag. For all the other flags it is easy to document that
\r
116 > notmuch_database_add_message_with_maildir_flags simply adds the
\r
117 > corresponding tag to the message. But we can't say that the presence of
\r
118 > the "S" tag prevents this function from adding the "unread" tag, since
\r
119 > this function never does add an "unread" tag.
\r
121 But can we say the the function _removes_ the unread tag if 'S' is
\r
122 present and adds it otherwise?
\r
124 > Instead, the setting of "unread" is taking place at a higher-level,
\r
125 > (inside "notmuch new"). So perhaps the right answer is for the library
\r
126 > function to add a "seen" tag, (making the handling of 'T' consistent
\r
127 > with all other tags and dropping the "inverse" field from the
\r
128 > table). Then, the "notmuch new" program can query the "seen" tag to
\r
129 > decide whether it should add its configured new_tags, ("inbox" and
\r
130 > "unread" by default).
\r
132 > I do want something like that anyway, because I want to make it so that
\r
133 > someone that first starts with notmuch and a large collection of maildir
\r
134 > messages doesn't end up with every message tagged as "inbox" after their
\r
135 > first run of "notmuch new".
\r
137 I understand your point but this change would break how I use notmuch
\r
138 now. My new_tags contains only "new" tag and if this tag is not added
\r
139 during notmuch new the message would not be properly tagged by my
\r
140 initial tagging script. I want to avoid the situation that I accidentaly
\r
141 view a message in a web-mail client, which adds the 'S' flag and this
\r
142 will lead to exclusion of the message from initial tagging.
\r
144 If we leave the things the way they are now, it should be easy for the
\r
147 notmuch tag -inbox not tag:unread
\r
149 We could also show this hint at the end of notmuch new when it is run
\r
150 for the first time and all messages are tagged by inbox.
\r
153 > So anyway, I'm currently working on implementing what I described
\r
154 > above. And I may change my mind slightly as I work through things.
\r
156 > I'll let you know,
\r
158 Great. I've finished the additional tests, which I send as a reply to
\r
159 this mail. Some test are marked as broken because I do not want to touch
\r
160 C sources while you are woking on them.
\r
projects / notmuch-archives.git / blob