Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello David,
>> # next line is a no-op, because it already doesn't have the unread tag
>> notmuch tag -unread folder:sent
>
> Seems also worth noting that to my mind it ultimately shouldn't be
> necessary to run that command -- notmuch should notice that one copy of
> the message has different maildir flags to the other in a way that's out
> of sync with the notmuch tags it has.
>

Right, that's probably a useful way to think about the problem.

>> The key point is that from notmuch's point of view the message never has
>> the unread tag, so there is no change for "notmuch tag" to sync with
>> maildir flags.
>>
>> It doesn't seem to make a difference if I put the copy in inbox/new or
>> inbox/cur, so I don't think it is related to the previous efforts not to
>> prematurely move files out of new/.
>>
>> As far as I can tell, notmuch-new (unlike notmuch-insert) does not call
>> notmuch_message_tags_to_maildir_flags, so the maildir flags on the newly
>> discovered copy are not updated. Perhaps it should, but that seems like
>> a pretty big change, so I want to proceed with caution.
>
> It makes sense to me for notmuch-new to call that function too, fwiw.

I have the same intuition. Unfortunately it is not as simple as adding
in a couple calls to this function. The complications I am aware of so
far are

1) We need to distinguish between when a newly discovered file should
update tags, and when the newly discovered file should have it's flags
updated.

2) Renaming files in the middle of notmuch new needs to be done
carefully in order that notmuch doesn't lose track of the files. They
are only lost until the next run of notmuch-new, but it's not ideal.

d


_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org