Closed bshanks closed 3 years ago
It would probably be better if both this and the --local-trash-tag functionality operated on the instance of Local
, it is not inconceivable that lieer will be used as a library. And as far as I can tell there is not anything stopping it from that yet (except it would not be thread-safe to operate on the same repo from several instances).
I rebased on master, and changed both this and the --local-trash-tag functionality to operate on the instance of Local. I made translate_labels and labels_translate into instance variables, and renamed the class variables (which serve as hardcoded defaults) to translate_labels_default and labels_translate_default.
I also removed the line
Local.update_translation('TRASH', self.local_trash_tag)
from set_local_trash_tag. I don't think we have access to a Local instance at that point, and I think it may not be necessary to actually apply the translation there, because I think that is called from within "gmi set" only?
Thanks, merged, and added a simple test -- our first one!
This PR adds a --translation-list-overlay option that allows additions and changes to the label/tag translation list. For example,
creates the mappings:
To give some idea why this might be useful, I have two Gmail accounts and I use filtering on the server to forward certain emails from account1 to account2, and then delete them from account1. However, if both are being sync'd to my local machine, then this filtering rule assigns a 'TRASH' label to the email in account1, which then in some cases is propagated to account2, causing the email to be deleted everywhere, which is not what i want. I am planning to try mapping 'TRASH' on account1 to 'trash_account1', and similarly for INBOX and for account2. In this way, the inbox/trash state of the email will be distinct for my two accounts, even though notmuch only maintains one set of tags for each message-id.