There's one big drawback I discovered the hard way, to not storing emails locally. If you have to leave an org for any reason, you lose access to the entire email history with that org. Some of which might still be important to you for a multitude of very legitimate reasons (such as contacts).
Aerc: A well-crafted TUI for email
121–130 of 166 posts
Re: Aerc: A well-crafted TUI for email
#122Re: Aerc: A well-crafted TUI for email
#123The problem with a TUI is that it’s a silo. Makes more sense to have pipeable, scriptable program(s) to retrieve/filter/sync/send. Then you can make several different UIs for it—vim, emacs, web, vscode, acme, thick client, etc—with a minimum of effort. TUI ends up re-implementing a good part of tmux unnecessarily.
The really messy part is the server - local maildir sync part. There are half a dozen or more tools to integrate. Mbsync, OfflineIMAP and msmtp are familiar to anyone doing 2-way syncing. But if you don't want mbsync waking up every 15mins to poll the IMAP server for new mails, or if you don't want to wait 15mins for new mail, you'll have to setup a mail push notifier that that's waiting for new mail using IMAP push protocols like IDLE. That's whole another setup, just to wake up mbsync when needed. But it's still only server to localdir sync. The reverse (using file change notifiers like inotify) requires an entirely different tool with a different setup.
To make it all worse, Google has decided that they don't need to follow the standard protocols, the same way as everyone else does (for easily guessable reasons). That means that gmail needs special sync configuration or even special sync tools like lieer.
And yet another issue is that IMAP (and SMTP) are old protocols with lots of optional features bolted on. We really need a better replacement for IMAP - something like JMAP. But very few providers, servers, sync tools (any?) or clients support it.
Re: Aerc: A well-crafted TUI for email
#124Re: Aerc: A well-crafted TUI for email
#125This seems like a perfect use case for a (local) LLM. Feed in the HTML and extract a clean plaintext version.
Re: Aerc: A well-crafted TUI for email
#126Re: Aerc: A well-crafted TUI for email
#127[flagged]
Re: Aerc: A well-crafted TUI for email
#128Earlier quoted context omitted.
> modern PERSONAL email tools The capitalized personal part there is so important! So few people today even realize what is possible, since they are captive in websites like gmail that have so very little functionality. email was always supposed to have a 100% customizable workflow, filtering, sorting, foldering, etc. We still have this of course, as all the old tools work. But there needs to be more awareness how gr…
I still use fetchmail, while I prefer MailDrop over procmail :-) And, yes, I 110% agree about automation revolving around emails, or simply revolving around exchanging text between people asynchronously. I still have my ascii ribbon campaign in the signature [well, mostly because I very lazy]. One of the first kind of automation, it's just mere handling, I have auto-delete for some mails not flagged, to keep my maild…
What a dream that would be!
Agree with everything above. In the 90s everything was trivially easy to automate and customize in any way one wanted. As the world has moved to ever more isolated siloed webapps that barely have any functionality built-in (which makes sense since every feature has to be built as a one-off addition to that specific website) and don't hook into or interoperate with any tools, we keep moving ever backwards in functionality and automatability.
This is not the future that was supposed to be.
Re: Aerc: A well-crafted TUI for email
#129Earlier quoted context omitted.
mutt is alive and well, it's all I use for email. At work I'm forced to use the unusable gmail website, ugh.
Curious what's unusable about gmail. I love the UI plus I also love the sidebar with tasks, calendar, etc. For me outlook is the real pain, I just redirect my emails there to my gmail.
Re: Aerc: A well-crafted TUI for email
#130Consider adding OAuth2.0 support. While Gmail IMAP/SMTP still supports Application Specific Passwords, you can see the writing on the wall, and the future is OAuth authentication.