FolderTagSync, a simplified mechanism maintaining 1-1 coorespondence between maildir folders and tags. about afew HOT 8 OPEN

BTW, there is a simpler way to handle the folder tags, but less flexible.
define a set of folder tags: { sent inbox spam trash}
then for each folder select which tag should be set
Sent Items = sent
Inbox = inbox
Junk Email = spam
Deleted Items = trash

But this lacks flexibility,

from afew.

No comments? The above FTS is implemented and currently under test (with my own mail), but if there is no interest then I will not pester the group with a PR.

from afew.

this approach is exactly what i am missing in afew right now. i am not using afew because it assumes it runs on a single workstation, while I have multiple. therefore i use state in the maildir as the reference to create tags in notmuch. for example, files moved to the "ham" folder get their "spam" tag removed and vice-versa. it's super tricky to implement, because you can get into a bouncing contest between the two workstations, for example.

i also use the F flag on messages to represent the inbox tag, which is also particularly tricky to implement.

this idea would possibly help me adopt afew.

from afew.

@anarcat , my deployment config is multi-client, multi-account. I'm using a cloud-based server to pull imap and gmail accounts with mbsync and lieer respectively. 3 different workstations then sync to server with muchsync. My intent is to run afew only on server as well, then muchsync will replicate its tagging on the workstations.

In what I have seen so far, I have 2 cases in which the bouncing does not converge to a single state.

1. a message is stored in multiple maildirs. I resolve this by simply refusing to FolderTag such messages. Just find and remove such duplicates. IMHO, seems contrary to the entire intent of notmuch, but would welcome enlightenment on usecase.
2. a FolderTag tag is ambiguous due to overloaded use. For example, the default inbox filter removes new (as it must), but also applies the inbox tag. That could be a problem if the new msg does not happen to reside in a inbox folder. Similarly with the spam and sent mail filters (I renamed the filter's sent to from-me tag to reserve sent as a FolderTag.

My current implementation requires the FolderTags to be added and removed atomically. E.g. moving a message from o365's inbox to deleted items requires +trash and -inbox. I thought that would be easy to handle from alot. But turns out that currently alot handles adds and removes as separate commands and the selected message can change between commands. Still trying to decide if the right answer is to add atomic add/remove to alot, or add configurable radio Tag Groups (like UI radio buttons) to notmuch (adding a tag from a configured group automagically removes all other group tags).

from afew.

1. a message is stored in multiple maildirs. I resolve this by simply refusing to FolderTag such messages. Just find and remove such duplicates. IMHO, seems contrary to the entire intent of notmuch, but would welcome enlightenment on usecase.

how do you actually deduplicate those? checksum? message-id? typically this happens on mailing lists where you receive a copy of your message...

from afew.

I just leveraged afew itself. Since notmuch tagging is applied at the message level, the de duplication needs to be to the notmuch message. I believe this is message-id and is definitely not a checksum. Fortunately, notmuch itself can find the duplicates for us.

I just temporarily used the message file iteration in my FolderTagSync implementation (similar to the one already in MailMover). When multiple files are found for a single message, the modified handler selected one to keep and moved the overs to a temp directory outside of the maildir. After de-duping the messages, I removed the temporary code.

Not really sure how I got my dupes. They were not from mailing lists (at least not the sample I looked at).

from afew.

Fwiw, I use a similar setup with folder/tag replication. In my case, I don't mind about duplicates (they are transparent with notmuch and disk space is not expensive) but I do mind about listing my >100 folders. I operate with a requirement to have identical names for folders and corresponding tags, i.e., messages in folder Folder/Subfolder will be tagged "+Folder/Subfolder -inbox". Then I use a pre-new script which moves files around before syncronizing. I'm still testing this setup: while it is true that it has worked very well for almost a year now, it is also true that I have some corner cases that need polishing.

I'll look into your solution (thanks for contributing!), but folder listing is a no-go.

from afew.

I did not remove the duplicates to save some disk space. Its that messages are tagged, not files. So its easier to prevent message bouncing between folders if the tags uniquely identify a folder and vice-versa. i.e. a 1-1 map.

However, I am reconsidering the above scheme. Its implemented and seems to be working well, but adding a folder is too fault prone. (In other words, I f'ed up adding a new folder myself. that's generally a bad sign :))

The major requirements I have is to support multiple accounts, each with a set of primary folders (inbox, trash, spam, sent). within inbox, I have topical folders. When I remove the inbox tag (without adding trash, spam) I want the topical tag to remain. That way I can (in a limited way) tag archived email from my phone by moving the email to a topical folder and then archiving it.

from afew.