Re: [RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"

[Carl Worth]

On Fri, 24 Jun 2011 22:34:03 +0200, Louis Rilling  wrote:
> 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?

That could very well be acceptable.

A user would have to carefully configure notmuch to get this
behavior. Options for that could include the following in
~/.notmuch-config:

[maildir]
synchronize_flags=false

Or:

[new]
tags=

I think that if either of the above options are set that notmuch won't
need to change the message's filename. And in that case, I would feel
that it wouldn't be entirely unreasonable for notmuch to leave message
in the "new" directory.

This allows the user to effectively setup a mail-store that notmuch
treats as more-or-less "read only" and that seems like a useful thing.

Please experiment with that and feel free to send the patch or patches
that you generate.

Thanks again, and I hope you can find a way to make notmuch work for
you.

-Carl


pgpnXQtogBjHY.pgp
Description: PGP signature
___
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/"

[Carl Worth]

On Fri, 24 Jun 2011 22:34:03 +0200, Louis Rilling  wrote:
> 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?

That could very well be acceptable.

A user would have to carefully configure notmuch to get this
behavior. Options for that could include the following in
~/.notmuch-config:

[maildir]
synchronize_flags=false

Or:

[new]
tags=

I think that if either of the above options are set that notmuch won't
need to change the message's filename. And in that case, I would feel
that it wouldn't be entirely unreasonable for notmuch to leave message
in the "new" directory.

This allows the user to effectively setup a mail-store that notmuch
treats as more-or-less "read only" and that seems like a useful thing.

Please experiment with that and feel free to send the patch or patches
that you generate.

Thanks again, and I hope you can find a way to make notmuch work for
you.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"

[Louis Rilling]

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/"

[Louis Rilling]

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
___
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/"

[Austin Clements]

Welcome to notmuch!

>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).

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).

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.

[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/"

[Austin Clements]

Welcome to notmuch!

>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).

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).

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.

[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
___
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/"

[Louis Rilling]

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_message_t *message);

 /* Freeze the current state of 'message' within the database.
  *
diff --git a/notmuch-client.h b/notmuch-client.h
index 63be337..2372fe6 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -235,6 +2

[RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"

[Louis Rilling]

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_message_t *message);
 
 /* Freeze the current state of 'message' within the database.
  *
diff --git a/notmuch-client.h b/notmuch-client.h
index 63be337..2372fe6 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -2