notmuchsync: handling of the deleted tag

[Sebastian Spaeth]

On 2010-09-22, Rob Browning wrote:
> In general, I think that until/unless notmuchsync can be more assured of
> doing the right thing, and in particular, if the deleted tag is likely
> to become official, notmuchsync should default to not setting it.
> 
> ...or at least, I'd prefer that.  Then I can add --tag-deleted if/when I
> want to.  Of course defaulting to --tag-deleted would also be OK, as
> long as there's a --no-tag-deleted.

In my workflow it does the right thing as I only "expire" a message if I
am happy that it actually will be deleted. The situation is a bit less
scary that it seemed to me: if a notmuch --revsync examines a mail file,
it is the exact copy that notmuch will point to, and it will mark that
as "deleted" (and eventually "--prune" can delete that very copy). A new
run by notmuchsync --revsync will then be told to look at the second
copy if the first is gone and it will discover that it does not have the
maildir flag "expired" and thus remove the "deleted" tag in the notmuch
db. As such, the tag should reflect the actual status of the mail file
that notmuch points to.

But I can imagine circumstances in which there would be an erroneous tag
be set and I don't want notmuchsync to accidently delete anyones emails,
so I'll disable the "deleted" tag synchronization by default and only
make it an option (that I will use). Solving this in a proper way will
require support from the notmuch API though.

Sebastian
P.S. cworth made clear that he preferred if there were no "official" tags
or some tags that are more queal than others.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100923/cfa7448b/attachment.pgp>