Quoth Neil Roberts on Apr 16 at 4:01 pm: > This option is similar to the existing new.tags option except that it > is instead used when a new filename is encountered for an existing > message. > > This can be used to do post-processing based on the filenames that a > message has. For example, in my setup I use maildrop to filter the > messages in to maildirs and then I have an extra script that runs to > add the tags based on which folders maildrop put the message in. The > script only looks at messages that have the 'inbox' tag and then > removes the tag after processing. This works fine except sometimes I > will get a message twice for example if I am CC'd in a message from a > mailing list. In that case I want the message to be tagged twice, once > to indicate it was sent directly to me and once to indicate it was > sent to the mailing list. If one of these messages is delayed then I > can end up processing the message once and removing the inbox tag. > When the second message is finally received it would previously not > get processed again so I would lose the second tag. With this patch I > can configure it to re-add the inbox tag in this case to force it to > reconsider the tags.
This is an interesting idea. Unfortunately, the duplicate message-ID code path you've modified is also used for rename detection. Hence, if the user modifies the maildir from another MUA, new.filename_tags will be applied if the message gets moved to another folder, or even if they simply change the maildir flags (e.g., marking the message read). I'm not sure exactly how your mail flow works, but would it be possible to use folder-based tagging in your post-new hook to accomplish this? E.g., notmuch tag +debian folder:debian Since this isn't filtered by any delivery tags, it will apply to any message that winds up in folder:debian, regardless of when it gets there.
