notes-organization-organizEmailTooling

new email folder ideas:

what is the problem i'm trying to solve?

thoughts:

proposal:

---

(note: you can use :exec what-key to see the name of a key in Mutt)

current email keyboard:

Home row: arst d h neio

a t n o: movement r: reply s: mbox e: delete i: treasure_chest h: flag

Big keys: enter, space: both display-message TODO: opportunity for something else here backspace: unbound Esc: leader key

Other index finger keys:

List of obvious opportunities:

enter, space: one of them could be something different backspace: unbound

consider a key for adding an email to a TODO list and also archiving it

--- ok i was considering lieer but:

https://www.reddit.com/r/planetemacs/comments/ebczkf/lieer_fast_emailfetching_and_twoway_tag/

Sort by User avatar level 1 singularineet 1 year ago

Gmailieer is a great tool. It's even a Debian package. I use it.

But, it's a bit of a hassle to set up (like, it gets confused about paths if you move stuff to other volumes and set up symbolic links) and there doesn't seem to be any nice way to tell it to not delete a message even if that message has been deleted remotely. Which means if you run it in a cron job and someone breaks into your Google account and deletes all your mail, your local copies will be automatically deleted. Or if your gmail account is getting near its quota so you delete everything older than two years, these messages will soon be deleted locally. Which isn't what I want. 1

---

so i'd better think harder about what i want, and about what's available:

so current proposal:

questions:

notes/later:

http://lieer.gaute.vetsj.com/#changing-ignored-tags-and-translation-after-initial-sync https://github.com/gauteh/lieer

might need:

    Python 3
    notmuch >= 0.25 python bindings
    google_api_python_client (sometimes google-api-python-client)
    oauth2client
    tqdm (optional - for progress bar)

plan:

lockbak)$/

Repository information and settings: Account ...........: THIS_EMAIL@gmail.com historyId .........: 0 lastmod ...........: 0 Timeout ...........: 600.000000 File extension ....: Remove local messages .....: True Drop non existing labels...: False Ignore empty history ......: False Replace . with / ..........: False Ignore tags (local) .......: set() Ignore labels (remote) ....: {'CATEGORY_SOCIAL', 'CATEGORY_PROMOTIONS', 'CATEGORY_FORUMS', 'CATEGORY_PERSO NAL', 'CATEGORY_UPDATES'} Trash tag (local) .........: trash

got: Account ...........: THIS_EMAIL@gmail.com historyId .........: 0 lastmod ...........: 0 Timeout ...........: 600.000000 File extension ....: Remove local messages .....: False Drop non existing labels...: False Ignore empty history ......: False Replace . with / ..........: True Ignore tags (local) .......: {'new'} Ignore labels (remote) ....: set() Trash tag (local) .........: deleted

CHAT CHAT SENT SENT INBOX INBOX IMPORTANT IMPORTANT TRASH TRASH DRAFT DRAFT SPAM SPAM CATEGORY_FORUMS CATEGORY_FORUMS CATEGORY_UPDATES CATEGORY_UPDATES CATEGORY_PERSONAL CATEGORY_PERSONAL CATEGORY_PROMOTIONS CATEGORY_PROMOTIONS CATEGORY_SOCIAL CATEGORY_SOCIAL STARRED STARRED UNREAD UNREAD

---

it would be nice to have two accounts but to also have a 'unified inbox' but:

https://mailman.neomutt.org/pipermail/neomutt-users-neomutt.org/2021-March/001001.html

also some users report that the numbers of new emails in the sidebar doesn't immediately update until you visit. Someone found a workaround but i forgot what it was.

i guess i could just accept going all-in on labels for now and annotate things that i would have saved to folder with a 'save' label. The folder i would have saved to would be a sender folder (the default in mutt) if no other labels, or another folder if there is another label.

so i'd need a neomutt macro that (a) removes the 'current business' labels, and (b) adds the 'save' label.

todo check out '21. Dynamically Changing $index_format using Patterns' in mutt manual!

---

eh, i guess getting rid of saving to folders and just using a 'deleted' tag instead (assuming that everything else is 'saved' in the archive) is the best short-term solution. Can always write a script later to save to folders based on sender. So there are then 5 tiers of saved stuff:

---

i think i'm going to have to convert everything to notmuch and lieer at once for this to work with a unified inbox:

so if the email you want to save is in an account using notmuch, you can't delete it from its folder when saving. But otherwise, you have to delete it from its folder when saving. And there is no way to do this conditionally.

could probably achieve conditional execution by using shell scripts or by doing something tricky with tags, since there is conditional execution specialized to the condition of whether or not there are currently any tagged messages. But may not be worth the complexity, since i might eventually want to convert my main mailbox to notmuch/lieer anyhow.

---

what if you delete a message from a lieer mailbox?

i tested this. If you delete from the client, it stays on the server (the way to delete from the server is to assign the 'trash' tag and then wait 30 days -- you can also delete immediately from the trash folder using the Gmail web client). If you delete an email from the client, then even though it persists on the server, on the client, it stays deleted and does not download again -- unless you manually do a 'gmi sync -f', in which case it re-downloads.

if you delete from the server, then, since i did "gmi set --no-remove-local-messages" for this repository, the deleted message stays on the client. It stays even if you do a 'gmi sync -f'. If you move a message to the trash on the server without permanently deleting, it adds a 'trash' tag to the message, which appears to hide it from virtual folders in the client, unless you search with tag:trash.

So, this meets my criteria: with this setup, it's hard for either the client or the server to cause unintentional permanent loss of email on the other.

---

ok so to convert my main mail directory:

CHAT CHAT SENT SENT INBOX INBOX IMPORTANT IMPORTANT TRASH TRASH DRAFT DRAFT SPAM SPAM CATEGORY_FORUMS CATEGORY_FORUMS CATEGORY_UPDATES CATEGORY_UPDATES CATEGORY_PERSONAL CATEGORY_PERSONAL CATEGORY_PROMOTIONS CATEGORY_PROMOTIONS CATEGORY_SOCIAL CATEGORY_SOCIAL STARRED STARRED UNREAD UNREAD

ok we got an email issue

i have some filters in one of my gmail accounts that fwds messages to another of my email accounts, and then deletes them from the original email account.

it seems that these messages got the 'trash' tag in the original account, that was synced down to my computer, and then, after a delay, since notmuch considers all copies of emails the same, it was synced back up to the second account. This means that in both accounts, the emails ended up in the 'trash' folder online, and hidden locally.

(weirdly, even though lieer has setting "Trash tag (local) .........: deleted" in both repos, i still see these messages tagged 'trash' locally)

Analysis:

How was the 'trash' tag added to the emails in the second account?

But what if the second account was synced first:

Some initial ideas:

Q: if a message has been seen by notmuch, and then is d/led from a new inbox during a gmi sync, and then 'notmuch new' is run on it, will 'new' be added to it again? I doubt it, but we can try and see. seems like yes, although i only did one test Does this help? Maybe not. I can't be sure that the notmuch posthook will execute in an atomic transaction along with the other notmuch stuff. If another notmuch process occurred while we were operating on 'new' then i don't think we'd be ableto prevent the inbox and trash tags from being sync'd across accounts.

oh, i have an idea. All the tags which we want to assign different values to in different accounts, just translate them to local tags with distinct names. So 'inbox' translates to 'inboxAcct1' or something like that, and the same with 'trash'. But lieer doesn't have an option for this. And local-trash-tag already seems buggy. But i could implement it. -- i think the bug is in local.py, in Config.__init__. I think it should call Local.update_translation('TRASH', self.local_trash_tag), which is currently called only in set_local_trash_tag, which i'm betting is only executed during the invocation when the relevant 'gmi set' is first given. -- could pass an assoc list (alternating key,value list) to encode an arbitrary set of translations into an option. -- so i guess i'll have 3 pull requests: fixing the exponential backoff undo to 1, fixing the trash bug, generalized translating updates LATER: i implemented this, and submitted a pull request to upstream. Works great, solves this problem.

if we're talking about implementing stuff, tho, the best thing would be to modify notmuch to not deduplicate different emails with the same message-id. They are probably using message-id as a primary key; we could make the primary key be the concatenation of the message-id and the containing folder path. well, if we did that, then the labels would not follow the message if it were copied to new folder

---

mb create a 'todomb' or 'should' folder for lower-priority/potential todos, but not as low as zzz/someday/mb? name? tdmb? shd? td0? later? low? todo-?

or should later, zzz, low, someday/mb all be the same concept?

what about the distinction b/t low priority toreads vs low priority todos? and what about 'work' fyis? low priority toreads could be the same as work fyis, and are still above fyi, i guess.

leaning towards: 'low' which would be an alternate 'mbox' for lower-priority stuff that i don't want to clutter 'mbox'

but now the naming is getting confusing; we have 'low' which contains something analogous to 'fyi'. low would be conceptually similar to the opposite of 'high', but 'high' is represented as an 'important' label on top of mbox, whereas low is an alternative to mbox.

could also have 'low' be a tag like 'important', but the opposite, and then replace the 'mbox' mailbox with low/med/high virtual mailboxes via queries

---

BayleShanks RecentChanges Bayle Shanks's website
Comments on notes-organization-organizEmailTooling This page is read-only View other revisions Administration
Last edited 2022-02-12 17:49 UTC by BayleShanks