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. At any rate, the change is certainly correct technically. A few nits 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 <l.rilling@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; The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE (though, admittedly, I don't know why; avoiding C99-isms?) > 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). > filename_new = (char *) talloc_size (ctx, > info - filename + > strlen (":2,") + flags_in_map + 1);