[PATCH 4/4] tags_to_maildir_flags: Don't rename if no flags change
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.
However, as Austin mentioned and according to the maildir specification,
messages living in "new/" are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from "new/" to
"cur/", only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the "new" status) users checking the "new"
status.
Changelog:
* v2: Fix bool type as well as NULL returned despite having no errors (Austin
Clements)
* v4: Tag the related test (contributed by Michal Sojka) as working
Signed-off-by: Louis Rilling
---
lib/message.cc| 12 +++-
test/maildir-sync |2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index b1b2942..c003729 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
* compute the new maildir filename.
*
* If the existing filename is in the directory "new", the new
- * filename will be in the directory "cur".
+ * filename will be in the directory "cur", unless no flags are changed.
*
* After a sequence of ":2," in the filename, any subsequent
* single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
char *filename_new, *dir;
char flag_map[128];
int flags_in_map = 0;
+notmuch_bool_t flags_changed = FALSE;
unsigned int i;
char *s;
@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+ flags_changed = TRUE;
}
}
@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+ flags_changed = TRUE;
}
}
+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+ return talloc_strdup (ctx, filename);
+
filename_new = (char *) talloc_size (ctx,
info - filename +
strlen (":2,") + flags_in_map + 1);
diff --git a/test/maildir-sync b/test/maildir-sync
index b3e90ae..e1ad81c 100755
--- a/test/maildir-sync
+++ b/test/maildir-sync
@@ -92,7 +92,7 @@ test_begin_subtest "Adding non-maildir tags does not move
message from new to cu
add_message [subject]='"Message to stay in new"' [date]='"Sat, 01 Jan 2000
12:00:00 -"' [filename]='message-to-stay-in-new' [dir]=new
notmuch tag +donotmove subject:"Message to stay in new"
output=$(cd "$MAIL_DIR"; ls */message-to-stay-in-new*)
-test_expect_equal_failure "$output" "new/message-to-stay-in-new"
+test_expect_equal "$output" "new/message-to-stay-in-new"
test_begin_subtest "Removing 'S' flag from existing filename adds 'unread' tag"
add_message [subject]='"Removing S flag"' [filename]='removing-s-flag:2,S'
[dir]=cur
--
1.7.2.5
[PATCH 3/4] test: Adding non-maildir tags does not move message from new to cur
From: Michal Sojka <so...@os.inf.tu-dresden.de> Some MUA's like mutt show the difference between "new" emails living in maildir directory new/, and "old" emails living in maildir directory cur/. However notmuch tag unconditionally moves selected messages from new/ to cur/, even if no maildir synchronized tag is changed. While maildir specification forbids messages with tags living in new/, there is no need to move messages to cur/ when no maildir synchronized tag is changed. Thus notmuch can remain transparent with respect to other MUA's. [ Edited commit log to better describe the intended changes, and tag the test as broken until the actual changes are implemented -- Louis Rilling ] Signed-off-by: Louis Rilling --- test/maildir-sync |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/test/maildir-sync b/test/maildir-sync index a60854f..b3e90ae 100755 --- a/test/maildir-sync +++ b/test/maildir-sync @@ -88,6 +88,12 @@ test_expect_equal "$output" "No new mail." # creating new directories in the mail store, then it should be # creating all necessary database state for those directories. +test_begin_subtest "Adding non-maildir tags does not move message from new to cur" +add_message [subject]='"Message to stay in new"' [date]='"Sat, 01 Jan 2000 12:00:00 -"' [filename]='message-to-stay-in-new' [dir]=new +notmuch tag +donotmove subject:"Message to stay in new" +output=$(cd "$MAIL_DIR"; ls */message-to-stay-in-new*) +test_expect_equal_failure "$output" "new/message-to-stay-in-new" + test_begin_subtest "Removing 'S' flag from existing filename adds 'unread' tag" add_message [subject]='"Removing S flag"' [filename]='removing-s-flag:2,S' [dir]=cur output=$(notmuch search subject:"Removing S flag" | notmuch_search_sanitize) -- 1.7.2.5
[PATCH 2/4] tags_to_maildir_flags: Cleanup double assignement
The for loop right after already does the job.
Signed-off-by: Louis Rilling
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index cf651e5..b1b2942 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _new_maildir_filename (void *ctx,
if (info == NULL) {
info = filename + strlen(filename);
} else {
- flags = info + 3;
-
/* Loop through existing flags in filename. */
for (flags = info + 3, last_flag = 0;
*flags;
--
1.7.2.5
[PATCH 1/4] lib: Kill last usage of C++ type bool
Signed-off-by: Louis Rilling
---
lib/message.cc | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index d993cde..cf651e5 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -49,16 +49,16 @@ struct visible _notmuch_message {
struct maildir_flag_tag {
char flag;
const char *tag;
-bool inverse;
+notmuch_bool_t inverse;
};
/* ASCII ordered table of Maildir flags and associated tags */
static struct maildir_flag_tag flag2tag[] = {
-{ 'D', "draft", false},
-{ 'F', "flagged", false},
-{ 'P', "passed", false},
-{ 'R', "replied", false},
-{ 'S', "unread", true }
+{ 'D', "draft", FALSE},
+{ 'F', "flagged", FALSE},
+{ 'P', "passed", FALSE},
+{ 'R', "replied", FALSE},
+{ 'S', "unread", TRUE }
};
/* We end up having to call the destructor explicitly because we had
--
1.7.2.5
[PATCH 0/4 v4] lib: Maildir flags synchronization fixes
Hello, Here is the updated series of fixes I have around maildir flags synchronization. The first two patches are just cleanups that can be applied independently. The intent for the fourth patch (detailed in the commit log) is to allow mutt users to keep using the "new" status, as long as notmuch can respect the maildir specification. The third patch implements a test for the new desired behavior. From recent discussions I decided to put it before the actual changes, but it certainly can move after if this is preferred. Changelog: * v4: - rebased on top of release 0.8 - included the test contributed by Michal Sojka * v3: Added patch to kill the last usage of C++ type bool * v2: Fix bool type as well as NULL returned despite having no errors (Austin Clements) Thanks, Louis Louis Rilling (3): lib: Kill last usage of C++ type bool tags_to_maildir_flags: Cleanup double assignement tags_to_maildir_flags: Don't rename if no flags change Michal Sojka (1): test: Adding non-maildir tags does not move message from new to cur lib/message.cc| 26 +- test/maildir-sync |6 ++ 2 files changed, 23 insertions(+), 9 deletions(-)
[PATCH 2/4] tags_to_maildir_flags: Cleanup double assignement
The for loop right after already does the job.
Signed-off-by: Louis Rilling l.rill...@av7.net
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index cf651e5..b1b2942 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _new_maildir_filename (void *ctx,
if (info == NULL) {
info = filename + strlen(filename);
} else {
- flags = info + 3;
-
/* Loop through existing flags in filename. */
for (flags = info + 3, last_flag = 0;
*flags;
--
1.7.2.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/4] test: Adding non-maildir tags does not move message from new to cur
From: Michal Sojka so...@os.inf.tu-dresden.de Some MUA's like mutt show the difference between new emails living in maildir directory new/, and old emails living in maildir directory cur/. However notmuch tag unconditionally moves selected messages from new/ to cur/, even if no maildir synchronized tag is changed. While maildir specification forbids messages with tags living in new/, there is no need to move messages to cur/ when no maildir synchronized tag is changed. Thus notmuch can remain transparent with respect to other MUA's. [ Edited commit log to better describe the intended changes, and tag the test as broken until the actual changes are implemented -- Louis Rilling ] Signed-off-by: Louis Rilling l.rill...@av7.net --- test/maildir-sync |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/test/maildir-sync b/test/maildir-sync index a60854f..b3e90ae 100755 --- a/test/maildir-sync +++ b/test/maildir-sync @@ -88,6 +88,12 @@ test_expect_equal $output No new mail. # creating new directories in the mail store, then it should be # creating all necessary database state for those directories. +test_begin_subtest Adding non-maildir tags does not move message from new to cur +add_message [subject]='Message to stay in new' [date]='Sat, 01 Jan 2000 12:00:00 -' [filename]='message-to-stay-in-new' [dir]=new +notmuch tag +donotmove subject:Message to stay in new +output=$(cd $MAIL_DIR; ls */message-to-stay-in-new*) +test_expect_equal_failure $output new/message-to-stay-in-new + test_begin_subtest Removing 'S' flag from existing filename adds 'unread' tag add_message [subject]='Removing S flag' [filename]='removing-s-flag:2,S' [dir]=cur output=$(notmuch search subject:Removing S flag | notmuch_search_sanitize) -- 1.7.2.5 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 4/4] tags_to_maildir_flags: Don't rename if no flags change
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory new/ to maildir directory cur/, which makes messages lose
their new status in the MUA. However some users want to keep this new
status after, for instance, an auto-tagging of new messages.
However, as Austin mentioned and according to the maildir specification,
messages living in new/ are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from new/ to
cur/, only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the new status) users checking the new
status.
Changelog:
* v2: Fix bool type as well as NULL returned despite having no errors (Austin
Clements)
* v4: Tag the related test (contributed by Michal Sojka) as working
Signed-off-by: Louis Rilling l.rill...@av7.net
---
lib/message.cc| 12 +++-
test/maildir-sync |2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index b1b2942..c003729 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
* compute the new maildir filename.
*
* If the existing filename is in the directory new, the new
- * filename will be in the directory cur.
+ * filename will be in the directory cur, unless no flags are changed.
*
* After a sequence of :2, in the filename, any subsequent
* single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
char *filename_new, *dir;
char flag_map[128];
int flags_in_map = 0;
+notmuch_bool_t flags_changed = FALSE;
unsigned int i;
char *s;
@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+ flags_changed = TRUE;
}
}
@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+ flags_changed = TRUE;
}
}
+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+ return talloc_strdup (ctx, filename);
+
filename_new = (char *) talloc_size (ctx,
info - filename +
strlen (:2,) + flags_in_map + 1);
diff --git a/test/maildir-sync b/test/maildir-sync
index b3e90ae..e1ad81c 100755
--- a/test/maildir-sync
+++ b/test/maildir-sync
@@ -92,7 +92,7 @@ test_begin_subtest Adding non-maildir tags does not move
message from new to cu
add_message [subject]='Message to stay in new' [date]='Sat, 01 Jan 2000
12:00:00 -' [filename]='message-to-stay-in-new' [dir]=new
notmuch tag +donotmove subject:Message to stay in new
output=$(cd $MAIL_DIR; ls */message-to-stay-in-new*)
-test_expect_equal_failure $output new/message-to-stay-in-new
+test_expect_equal $output new/message-to-stay-in-new
test_begin_subtest Removing 'S' flag from existing filename adds 'unread' tag
add_message [subject]='Removing S flag' [filename]='removing-s-flag:2,S'
[dir]=cur
--
1.7.2.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] notmuch restore --accumulate
On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote: > Also, we generally prefer to have modifications to the test suite in > separate patches that precede the patches that add the features/fix the > bugs. > For new features, this does not look like 'git bisect'-safe. I would say that the testsuite patch should follow the new feature patch, don't you? Thanks, Louis > > Signed-off-by: Thomas Schwinge > > Finally, you don't need to sign off on your own patches. > > Thanks. > > jamie. > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] notmuch restore --accumulate
On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote: Also, we generally prefer to have modifications to the test suite in separate patches that precede the patches that add the features/fix the bugs. For new features, this does not look like 'git bisect'-safe. I would say that the testsuite patch should follow the new feature patch, don't you? Thanks, Louis Signed-off-by: Thomas Schwinge tho...@schwinge.name Finally, you don't need to sign off on your own patches. Thanks. jamie. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: Adding non-maildir tags does not move message from new to cur
On 14/07/11 2:06 +0200, Michal Sojka wrote: > From: Michal Sojka > > This adds a test for patch submitted by Louis Rilling. Without his patch > applied this test fails. Thanks a lot Michal! I was indeed wondering how to do this. This test perfectly matches the intended usage. Louis > --- > test/maildir-sync |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/test/maildir-sync b/test/maildir-sync > index a60854f..e1ad81c 100755 > --- a/test/maildir-sync > +++ b/test/maildir-sync > @@ -88,6 +88,12 @@ test_expect_equal "$output" "No new mail." > # creating new directories in the mail store, then it should be > # creating all necessary database state for those directories. > > +test_begin_subtest "Adding non-maildir tags does not move message from new > to cur" > +add_message [subject]='"Message to stay in new"' [date]='"Sat, 01 Jan 2000 > 12:00:00 -"' [filename]='message-to-stay-in-new' [dir]=new > +notmuch tag +donotmove subject:"Message to stay in new" > +output=$(cd "$MAIL_DIR"; ls */message-to-stay-in-new*) > +test_expect_equal "$output" "new/message-to-stay-in-new" > + > test_begin_subtest "Removing 'S' flag from existing filename adds 'unread' > tag" > add_message [subject]='"Removing S flag"' [filename]='removing-s-flag:2,S' > [dir]=cur > output=$(notmuch search subject:"Removing S flag" | notmuch_search_sanitize) > -- > 1.7.5.4 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: Adding non-maildir tags does not move message from new to cur
On 14/07/11 2:06 +0200, Michal Sojka wrote: From: Michal Sojka so...@os.inf.tu-dresden.de This adds a test for patch submitted by Louis Rilling. Without his patch applied this test fails. Thanks a lot Michal! I was indeed wondering how to do this. This test perfectly matches the intended usage. Louis --- test/maildir-sync |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/test/maildir-sync b/test/maildir-sync index a60854f..e1ad81c 100755 --- a/test/maildir-sync +++ b/test/maildir-sync @@ -88,6 +88,12 @@ test_expect_equal $output No new mail. # creating new directories in the mail store, then it should be # creating all necessary database state for those directories. +test_begin_subtest Adding non-maildir tags does not move message from new to cur +add_message [subject]='Message to stay in new' [date]='Sat, 01 Jan 2000 12:00:00 -' [filename]='message-to-stay-in-new' [dir]=new +notmuch tag +donotmove subject:Message to stay in new +output=$(cd $MAIL_DIR; ls */message-to-stay-in-new*) +test_expect_equal $output new/message-to-stay-in-new + test_begin_subtest Removing 'S' flag from existing filename adds 'unread' tag add_message [subject]='Removing S flag' [filename]='removing-s-flag:2,S' [dir]=cur output=$(notmuch search subject:Removing S flag | notmuch_search_sanitize) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/3] tags_to_maildir_flags: Cleanup double assignement
The for loop right after already does the job.
Signed-off-by: Louis Rilling
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index cf651e5..b1b2942 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _new_maildir_filename (void *ctx,
if (info == NULL) {
info = filename + strlen(filename);
} else {
- flags = info + 3;
-
/* Loop through existing flags in filename. */
for (flags = info + 3, last_flag = 0;
*flags;
--
1.7.2.5
[PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change
On 11/07/11 20:03 -0400, Austin Clements wrote:
> > > The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE
> > > (though, admittedly, I don't know why; avoiding C99-isms?)
> >
> > And bool is already used at another place in message.cc:
> >
> > struct maildir_flag_tag {
> > char flag;
> > const char *tag;
> > bool inverse;
> > };
> >
> > IIUC it should be changed to notmuch_bool_t too.
>
> Yes, I suppose it should (something slipped by cworth's eagle-eyed
> reviews!). Though that appears to be the sole use of bool in all of
> libnotmuch.
I wonder if this is due to incompatible definitions of type bool in C99 and
C++. In that case this is probably harmless since struct maildir_flag_tag is
only visible from message.cc. Anyway, I'm sending a conversion patch together
with the updated series to make it clearer for Carl.
Thanks,
Louis
[PATCH v2] tags_to_maildir_flags: Don't rename if no flags change
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.
However, as Austin mentioned and according to the maildir specification,
messages living in "new/" are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from "new/" to
"cur/", only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the "new" status) users checking the "new"
status.
Changelog:
* v2: Fix bool type as well as NULL returned despite having no errors (Austin
Clements)
Signed-off-by: Louis Rilling
---
lib/message.cc | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 64b6cf8..3f8c4ba 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
* compute the new maildir filename.
*
* If the existing filename is in the directory "new", the new
- * filename will be in the directory "cur".
+ * filename will be in the directory "cur", unless no flags are changed.
*
* After a sequence of ":2," in the filename, any subsequent
* single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
char *filename_new, *dir;
char flag_map[128];
int flags_in_map = 0;
+notmuch_bool_t flags_changed = FALSE;
unsigned int i;
char *s;
@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+ flags_changed = TRUE;
}
}
@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+ flags_changed = TRUE;
}
}
+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+ return talloc_strdup (ctx, filename);
+
filename_new = (char *) talloc_size (ctx,
info - filename +
strlen (":2,") + flags_in_map + 1);
--
1.7.2.5
[PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change
On 11/07/11 16:07 -0400, Austin Clements wrote:
> I worry that this may compound the confusion caused by mutt's handling
> of the new flag, but I suppose people aren't likely to manipulate any
> of the other maildir-synchronized flags without also marking the
> message as seen.
Even if they don't mark the message as seen, any flag changed would move the
message to cur/. The only buggy behavior would be from mutt, with the bug you
mentioned about mutt putting messages with flags back to new/.
> At any rate, the change is certainly correct
> technically. A few nits below.
They should be addressed by the follow-up patch. Just a comment below.
>
> Quoth Louis Rilling on Jul 11 at 4:36 pm:
> > notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
> > maildir directory "new/" to maildir directory "cur/", which makes messages
> > lose
> > their "new" status in the MUA. However some users want to keep this "new"
> > status after, for instance, an auto-tagging of new messages.
> >
> > However, as Austin mentioned and according to the maildir specification,
> > messages living in "new/" are not allowed to have flags, even if mutt
> > allows it
> > to happen. For this reason, this patch prevents moving messages from "new/"
> > to
> > "cur/", only if no flags have to be changed. It's hopefully enough to
> > satisfy
> > mutt (and maybe other MUAs showing the "new" status) users checking the
> > "new"
> > status.
> >
> > Signed-off-by: Louis Rilling
> > ---
> > lib/message.cc | 12 +++-
> > 1 files changed, 11 insertions(+), 1 deletions(-)
> >
> > diff --git a/lib/message.cc b/lib/message.cc
> > index 64b6cf8..131d99b 100644
> > --- a/lib/message.cc
> > +++ b/lib/message.cc
> > @@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
> > * compute the new maildir filename.
> > *
> > * If the existing filename is in the directory "new", the new
> > - * filename will be in the directory "cur".
> > + * filename will be in the directory "cur", unless no flags are changed.
> > *
> > * After a sequence of ":2," in the filename, any subsequent
> > * single-character flags will be added or removed according to the
> > @@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
> > char *filename_new, *dir;
> > char flag_map[128];
> > int flags_in_map = 0;
> > +bool flags_changed = false;
>
> The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE
> (though, admittedly, I don't know why; avoiding C99-isms?)
And bool is already used at another place in message.cc:
struct maildir_flag_tag {
char flag;
const char *tag;
bool inverse;
};
IIUC it should be changed to notmuch_bool_t too.
>
> > unsigned int i;
> > char *s;
> >
> > @@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
> > if (flag_map[flag] == 0) {
> > flag_map[flag] = 1;
> > flags_in_map++;
> > + flags_changed = true;
> > }
> > }
> >
> > @@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
> > if (flag_map[flag]) {
> > flag_map[flag] = 0;
> > flags_in_map--;
> > + flags_changed = true;
> > }
> > }
> >
> > +/* No need to rename. Messages in new/ can be kept in new/.
> > + * Note: We don't even try to fix buggy messages having flags and
> > living in
> > + * new/. It's not our business.
> > + */
> > +if (!flags_changed)
> > + return NULL;
> > +
>
> NULL generally indicates an error in notmuch and is currently used
> that way in _new_maildir_filename, so even though the caller currently
> doesn't really care, I'd lean against overloading it to indicate that
> the filename doesn't need to change. Despite the slight inefficiency,
> I would recommend returning talloc_strdup (ctx, filename).
Ok.
Thanks,
Louis
>
> > filename_new = (char *) talloc_size (ctx,
> > info - filename +
> > strlen (":2,") + flags_in_map + 1);
Re: [PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change
On 11/07/11 20:03 -0400, Austin Clements wrote:
The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE
(though, admittedly, I don't know why; avoiding C99-isms?)
And bool is already used at another place in message.cc:
struct maildir_flag_tag {
char flag;
const char *tag;
bool inverse;
};
IIUC it should be changed to notmuch_bool_t too.
Yes, I suppose it should (something slipped by cworth's eagle-eyed
reviews!). Though that appears to be the sole use of bool in all of
libnotmuch.
I wonder if this is due to incompatible definitions of type bool in C99 and
C++. In that case this is probably harmless since struct maildir_flag_tag is
only visible from message.cc. Anyway, I'm sending a conversion patch together
with the updated series to make it clearer for Carl.
Thanks,
Louis
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/3 v3] lib: Maildir flags synchronization fixes
Hello Carl, Here is the updated series of fixes I have around maildir flags synchronization. The first two patches are just cleanups that can be applied independently. The intent for the third patch (detailed in the commit log) is to allow mutt users to keep using the new status, as long as notmuch can respect the maildir specification. Changelog: * v3: Added patch to kill the last usage of C++ type bool * v2: Fix bool type as well as NULL returned despite having no errors (Austin Clements) Thanks, Louis Louis Rilling (3): lib: Kill last usage of C++ type bool tags_to_maildir_flags: Cleanup double assignement tags_to_maildir_flags: Don't rename if no flags change lib/message.cc | 26 +- 1 files changed, 17 insertions(+), 9 deletions(-) -- 1.7.2.5 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] lib: Kill last usage of C++ type bool
Signed-off-by: Louis Rilling l.rill...@av7.net
---
lib/message.cc | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index d993cde..cf651e5 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -49,16 +49,16 @@ struct visible _notmuch_message {
struct maildir_flag_tag {
char flag;
const char *tag;
-bool inverse;
+notmuch_bool_t inverse;
};
/* ASCII ordered table of Maildir flags and associated tags */
static struct maildir_flag_tag flag2tag[] = {
-{ 'D', draft, false},
-{ 'F', flagged, false},
-{ 'P', passed, false},
-{ 'R', replied, false},
-{ 'S', unread, true }
+{ 'D', draft, FALSE},
+{ 'F', flagged, FALSE},
+{ 'P', passed, FALSE},
+{ 'R', replied, FALSE},
+{ 'S', unread, TRUE }
};
/* We end up having to call the destructor explicitly because we had
--
1.7.2.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/3] tags_to_maildir_flags: Cleanup double assignement
The for loop right after already does the job.
Signed-off-by: Louis Rilling l.rill...@av7.net
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index cf651e5..b1b2942 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _new_maildir_filename (void *ctx,
if (info == NULL) {
info = filename + strlen(filename);
} else {
- flags = info + 3;
-
/* Loop through existing flags in filename. */
for (flags = info + 3, last_flag = 0;
*flags;
--
1.7.2.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.
However, as Austin mentioned and according to the maildir specification,
messages living in "new/" are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from "new/" to
"cur/", only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the "new" status) users checking the "new"
status.
Signed-off-by: Louis Rilling
---
lib/message.cc | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 64b6cf8..131d99b 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
* compute the new maildir filename.
*
* If the existing filename is in the directory "new", the new
- * filename will be in the directory "cur".
+ * filename will be in the directory "cur", unless no flags are changed.
*
* After a sequence of ":2," in the filename, any subsequent
* single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
char *filename_new, *dir;
char flag_map[128];
int flags_in_map = 0;
+bool flags_changed = false;
unsigned int i;
char *s;
@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+ flags_changed = true;
}
}
@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+ flags_changed = true;
}
}
+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+ return NULL;
+
filename_new = (char *) talloc_size (ctx,
info - filename +
strlen (":2,") + flags_in_map + 1);
--
1.7.2.5
[PATCH 1/2] tags_to_maildir_flags: Cleanup double assignement
The for loop right after already does the job.
Signed-off-by: Louis Rilling
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index d993cde..64b6cf8 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _new_maildir_filename (void *ctx,
if (info == NULL) {
info = filename + strlen(filename);
} else {
- flags = info + 3;
-
/* Loop through existing flags in filename. */
for (flags = info + 3, last_flag = 0;
*flags;
--
1.7.2.5
[PATCH 0/2] lib: Don't always move from maildir new/ to maildir cur/
Hello, Here is an alternative, as we discussed earlier. This is enough to keep me using mutt's ability to show the "new" status, and to allow me to test notmuch with my real emails. Altough my notmuch config uses [new] tags=new; [maildir] synchronize_flags=true messages will be kept in "new/", even with [new] tags=inbox;unread; [maildir] synchronize_flags=true as long as no maildir flags have to be changed. The first patch can be applied independently. Thanks, Louis Louis Rilling (2): tags_to_maildir_flags: Cleanup double assignement tags_to_maildir_flags: Don't rename if no flags change lib/message.cc | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) -- 1.7.2.5
[PATCH 0/2] lib: Don't always move from maildir new/ to maildir cur/
Hello, Here is an alternative, as we discussed earlier. This is enough to keep me using mutt's ability to show the new status, and to allow me to test notmuch with my real emails. Altough my notmuch config uses [new] tags=new; [maildir] synchronize_flags=true messages will be kept in new/, even with [new] tags=inbox;unread; [maildir] synchronize_flags=true as long as no maildir flags have to be changed. The first patch can be applied independently. Thanks, Louis Louis Rilling (2): tags_to_maildir_flags: Cleanup double assignement tags_to_maildir_flags: Don't rename if no flags change lib/message.cc | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) -- 1.7.2.5 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] tags_to_maildir_flags: Cleanup double assignement
The for loop right after already does the job.
Signed-off-by: Louis Rilling l.rill...@av7.net
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index d993cde..64b6cf8 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _new_maildir_filename (void *ctx,
if (info == NULL) {
info = filename + strlen(filename);
} else {
- flags = info + 3;
-
/* Loop through existing flags in filename. */
for (flags = info + 3, last_flag = 0;
*flags;
--
1.7.2.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory new/ to maildir directory cur/, which makes messages lose
their new status in the MUA. However some users want to keep this new
status after, for instance, an auto-tagging of new messages.
However, as Austin mentioned and according to the maildir specification,
messages living in new/ are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from new/ to
cur/, only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the new status) users checking the new
status.
Signed-off-by: Louis Rilling l.rill...@av7.net
---
lib/message.cc | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 64b6cf8..131d99b 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
* compute the new maildir filename.
*
* If the existing filename is in the directory new, the new
- * filename will be in the directory cur.
+ * filename will be in the directory cur, unless no flags are changed.
*
* After a sequence of :2, in the filename, any subsequent
* single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
char *filename_new, *dir;
char flag_map[128];
int flags_in_map = 0;
+bool flags_changed = false;
unsigned int i;
char *s;
@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+ flags_changed = true;
}
}
@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+ flags_changed = true;
}
}
+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+ return NULL;
+
filename_new = (char *) talloc_size (ctx,
info - filename +
strlen (:2,) + flags_in_map + 1);
--
1.7.2.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] tags_to_maildir_flags: Don't rename if no flags change
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory new/ to maildir directory cur/, which makes messages lose
their new status in the MUA. However some users want to keep this new
status after, for instance, an auto-tagging of new messages.
However, as Austin mentioned and according to the maildir specification,
messages living in new/ are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from new/ to
cur/, only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the new status) users checking the new
status.
Changelog:
* v2: Fix bool type as well as NULL returned despite having no errors (Austin
Clements)
Signed-off-by: Louis Rilling l.rill...@av7.net
---
lib/message.cc | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 64b6cf8..3f8c4ba 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
* compute the new maildir filename.
*
* If the existing filename is in the directory new, the new
- * filename will be in the directory cur.
+ * filename will be in the directory cur, unless no flags are changed.
*
* After a sequence of :2, in the filename, any subsequent
* single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
char *filename_new, *dir;
char flag_map[128];
int flags_in_map = 0;
+notmuch_bool_t flags_changed = FALSE;
unsigned int i;
char *s;
@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+ flags_changed = TRUE;
}
}
@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+ flags_changed = TRUE;
}
}
+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+ return talloc_strdup (ctx, filename);
+
filename_new = (char *) talloc_size (ctx,
info - filename +
strlen (:2,) + flags_in_map + 1);
--
1.7.2.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"
On 24/06/11 11:19 -0400, Austin Clements wrote: > Welcome to notmuch! Thanks! > > From your description, I assume you're using both notmuch and another > MUA simultaneously. I'm betting that MUA is mutt (though please > correct me if I'm wrong). Correct :) > > Unfortunately, mutt's interpretation of maildir doesn't agree with the > rest of the world. I don't know of any other MUA that exposes the > distinction between mail in the "new" directory and mail in the "old" > directory (at least Dovecot, Evolution, Gnus, Kmail, and of course > notmuch don't). In other MUA's, any mail in the "new" directory is > immediately moved to "cur" and "new" mail is simply anything without > the seen flag. mutt, on the other hand, only considers mail in the > "new" directory to be "new". > > While the maildir specification is a little vague, it strongly implies > two things that mutt's approach violates: mail should never move from > "cur" to "new", and only mail in "cur" can have flags [1]. While it > never states it outright, the philosophy is that "new" is simply a > staging ground for incoming mail, not a user-visible state (and > certainly not user-manipulable). Thanks for the detailed explanation. > > Because of this, I don't think notmuch is the right place to change > this (certainly not in a way that would also violate the spec). Could > you elaborate a bit on your workflow? (In particular, are you using > mutt's distinction between new and old?) Maybe we can find an > alternate solution. Yes my quick "mood-dependent" filtering just acts on new (as shown by mutt) mails, while old mails are kept until either 1) they can be read (yes, this happens!), or 2) they can be archived (because they might be interesting in some future), or 3) they can be deleted (eg. became too old to be worth reading them). However, I don't think that I need the violating behavior of mutt: new mails are just new, not replied to/read, or anything else. The only rare cases in which I may set back the new flag are when I mistakenly start reading an email (wrong keystroke most of the time). Even in that case, I don't care if the mail becomes old (ie moves to cur/). Maybe the alternate solution could consist in simply not renaming emails having no flags to be changed (Currently notmuch_message_tags_to_maildir_flags() unconditionally moves messages from new/ to cur/). This would even lead to a shorter patch :) Do you think that this would be acceptable? Thanks, Louis > > [1] There's a bug open about the second problem (thanks to ccxCZ for > finding this): > http://dev.mutt.org/trac/ticket/2476 > Of course, fixing that implies addressing the first problem, too. > > On Thu, Jun 23, 2011 at 11:36 AM, Louis Rilling wrote: > > notmuch_message_tags_to_maildir_flags() moves messages from maildir > > directory > > "new/" to maildir directory "cur/", which makes messages lose their "new" > > status > > in the MUA. However some users want to keep this "new" status after, for > > instance, an auto-tagging of new messages. > > > > This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), > > which > > does the same job as notmuch_message_tags_to_maildir_flags() except moving > > from "maildir "new/" to maildir "cur/". A new option "preserve_new" is > > introduced in "[maildir]" section of .notmuch-config, so that users can > > configure whether commands "notmuch tag" and "notmuch restore" preserve the > > "new" status or not. > > > > Signed-off-by: Louis Rilling > > --- > > Hi, > > > > I'm in the process of using notmuch, but the issue "addressed" by this patch > > would make me change my habits a bit too fast. I use the "new" status for > > quickly checking (often without reading) which emails I just received, > > implementing some kind of context/mood/daytime-dependent quick filtering. > > I'd > > also like to run a pre-tagging script automatically when synchronizing > > periodically (and automatically too) my mailboxes. But the current behavior > > of > > "notmuch tag" makes me lose my quick filtering ability. > > > > This patch is mostly written for discussion. It is certainly not polished > > (API, > > ABI, bindings) and not tested at all. In particular, I know that there are > > some > > plans to customize flags synchronization, but I don't know how the library > > API > > could/should be impacted. > > > > Thanks for your comments! > > > > Louis
Re: [RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from new/ to cur/
On 24/06/11 11:19 -0400, Austin Clements wrote: Welcome to notmuch! Thanks! From your description, I assume you're using both notmuch and another MUA simultaneously. I'm betting that MUA is mutt (though please correct me if I'm wrong). Correct :) Unfortunately, mutt's interpretation of maildir doesn't agree with the rest of the world. I don't know of any other MUA that exposes the distinction between mail in the new directory and mail in the old directory (at least Dovecot, Evolution, Gnus, Kmail, and of course notmuch don't). In other MUA's, any mail in the new directory is immediately moved to cur and new mail is simply anything without the seen flag. mutt, on the other hand, only considers mail in the new directory to be new. While the maildir specification is a little vague, it strongly implies two things that mutt's approach violates: mail should never move from cur to new, and only mail in cur can have flags [1]. While it never states it outright, the philosophy is that new is simply a staging ground for incoming mail, not a user-visible state (and certainly not user-manipulable). Thanks for the detailed explanation. Because of this, I don't think notmuch is the right place to change this (certainly not in a way that would also violate the spec). Could you elaborate a bit on your workflow? (In particular, are you using mutt's distinction between new and old?) Maybe we can find an alternate solution. Yes my quick mood-dependent filtering just acts on new (as shown by mutt) mails, while old mails are kept until either 1) they can be read (yes, this happens!), or 2) they can be archived (because they might be interesting in some future), or 3) they can be deleted (eg. became too old to be worth reading them). However, I don't think that I need the violating behavior of mutt: new mails are just new, not replied to/read, or anything else. The only rare cases in which I may set back the new flag are when I mistakenly start reading an email (wrong keystroke most of the time). Even in that case, I don't care if the mail becomes old (ie moves to cur/). Maybe the alternate solution could consist in simply not renaming emails having no flags to be changed (Currently notmuch_message_tags_to_maildir_flags() unconditionally moves messages from new/ to cur/). This would even lead to a shorter patch :) Do you think that this would be acceptable? Thanks, Louis [1] There's a bug open about the second problem (thanks to ccxCZ for finding this): http://dev.mutt.org/trac/ticket/2476 Of course, fixing that implies addressing the first problem, too. On Thu, Jun 23, 2011 at 11:36 AM, Louis Rilling l.rill...@av7.net wrote: notmuch_message_tags_to_maildir_flags() moves messages from maildir directory new/ to maildir directory cur/, which makes messages lose their new status in the MUA. However some users want to keep this new status after, for instance, an auto-tagging of new messages. This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), which does the same job as notmuch_message_tags_to_maildir_flags() except moving from maildir new/ to maildir cur/. A new option preserve_new is introduced in [maildir] section of .notmuch-config, so that users can configure whether commands notmuch tag and notmuch restore preserve the new status or not. Signed-off-by: Louis Rilling l.rill...@av7.net --- Hi, I'm in the process of using notmuch, but the issue addressed by this patch would make me change my habits a bit too fast. I use the new status for quickly checking (often without reading) which emails I just received, implementing some kind of context/mood/daytime-dependent quick filtering. I'd also like to run a pre-tagging script automatically when synchronizing periodically (and automatically too) my mailboxes. But the current behavior of notmuch tag makes me lose my quick filtering ability. This patch is mostly written for discussion. It is certainly not polished (API, ABI, bindings) and not tested at all. In particular, I know that there are some plans to customize flags synchronization, but I don't know how the library API could/should be impacted. Thanks for your comments! Louis ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"
notmuch_message_tags_to_maildir_flags() moves messages from maildir directory
"new/" to maildir directory "cur/", which makes messages lose their "new" status
in the MUA. However some users want to keep this "new" status after, for
instance, an auto-tagging of new messages.
This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), which
does the same job as notmuch_message_tags_to_maildir_flags() except moving
from "maildir "new/" to maildir "cur/". A new option "preserve_new" is
introduced in "[maildir]" section of .notmuch-config, so that users can
configure whether commands "notmuch tag" and "notmuch restore" preserve the
"new" status or not.
Signed-off-by: Louis Rilling
---
Hi,
I'm in the process of using notmuch, but the issue "addressed" by this patch
would make me change my habits a bit too fast. I use the "new" status for
quickly checking (often without reading) which emails I just received,
implementing some kind of context/mood/daytime-dependent quick filtering. I'd
also like to run a pre-tagging script automatically when synchronizing
periodically (and automatically too) my mailboxes. But the current behavior of
"notmuch tag" makes me lose my quick filtering ability.
This patch is mostly written for discussion. It is certainly not polished (API,
ABI, bindings) and not tested at all. In particular, I know that there are some
plans to customize flags synchronization, but I don't know how the library API
could/should be impacted.
Thanks for your comments!
Louis
lib/message.cc| 33 +
lib/notmuch.h |7 +++
notmuch-client.h |7 +++
notmuch-config.c | 35 ++-
notmuch-restore.c | 10 --
notmuch-tag.c | 10 --
6 files changed, 89 insertions(+), 13 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 4b59fa9..c6c4160 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1130,7 +1130,8 @@ static char*
_new_maildir_filename (void *ctx,
const char *filename,
const char *flags_to_set,
- const char *flags_to_clear)
+ const char *flags_to_clear,
+ bool preserve_new)
{
const char *info, *flags;
unsigned int flag, last_flag;
@@ -1211,16 +1212,19 @@ _new_maildir_filename (void *ctx,
}
*s = '\0';
-/* If message is in new/ move it under cur/. */
-dir = (char *) _filename_is_in_maildir (filename_new);
-if (dir && STRNCMP_LITERAL (dir, "new/") == 0)
- memcpy (dir, "cur/", 4);
+if (!preserve_new) {
+ /* If message is in new/ move it under cur/. */
+ dir = (char *) _filename_is_in_maildir (filename_new);
+ if (dir && STRNCMP_LITERAL (dir, "new/") == 0)
+ memcpy (dir, "cur/", 4);
+}
return filename_new;
}
-notmuch_status_t
-notmuch_message_tags_to_maildir_flags (notmuch_message_t *message)
+static notmuch_status_t
+_notmuch_message_tags_to_maildir_flags (notmuch_message_t *message,
+ bool preserve_new)
{
notmuch_filenames_t *filenames;
const char *filename;
@@ -1240,7 +1244,8 @@ notmuch_message_tags_to_maildir_flags (notmuch_message_t
*message)
continue;
filename_new = _new_maildir_filename (message, filename,
- to_set, to_clear);
+ to_set, to_clear,
+ preserve_new);
if (filename_new == NULL)
continue;
@@ -1281,6 +1286,18 @@ notmuch_message_tags_to_maildir_flags (notmuch_message_t
*message)
}
notmuch_status_t
+notmuch_message_tags_to_maildir_flags (notmuch_message_t *message)
+{
+_notmuch_message_tags_to_maildir_flags(message, false);
+}
+
+notmuch_status_t
+notmuch_message_tags_to_maildir_flags_preserve (notmuch_message_t *message)
+{
+_notmuch_message_tags_to_maildir_flags(message, true);
+}
+
+notmuch_status_t
notmuch_message_remove_all_tags (notmuch_message_t *message)
{
notmuch_private_status_t private_status;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index e508309..eeddc17 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -978,6 +978,13 @@ notmuch_message_maildir_flags_to_tags (notmuch_message_t
*message);
*/
notmuch_status_t
notmuch_message_tags_to_maildir_flags (notmuch_message_t *message);
+/* Rename message filename(s) to encode tags as maildir flags, without moving
from new/ to cur/
+ *
+ * Same as notmuch_message_tags_to_maildir_flags, but messages living in
+ * directory "new" are not moved to neighboring directory "cur".
+ */
+notmuch_status_t
+notmuch_message_tags_to_maildir_flags_preserve (notmuch_me
