Live data from Hacker News

Aerc: A well-crafted TUI for email

blog.sergeantbiggs.net

121–130 of 166 posts

Re: Aerc: A well-crafted TUI for email

#121

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).

You're right about keeping an offline copy of emails - especially with the help of an indexer like notmuch or mu. But I'm not sure why you mentioned it here. In case you think that aerc supports only IMAP, it has good integration with local maildirs and notmuch. Somebody else mentioned that maildir support felt like a second class citizen. This was true during the initial phase of the project. But the developers changed their mind some time later (there's a blog post about it somewhere) and gave it a better UX.

Re: Aerc: A well-crafted TUI for email

#123

The 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.

Notmuch (any perhaps mu) is perhaps the silver bullet you're looking for. Easily searchable, filter friendly and very much scriptable. Many TUIs including aerc and mutt can act as frontends for notmuch - though configuration may be hard. Notmuch is also supported by 'afew' - an initial mail tagger based on conditions you set (kind of like sieve, on the client side). This makes filtering of even new mails very easy. In all, I'm pretty satisfied with that side - with notmuch providing much of the flexibility and integration.

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

#125
> In most multipart emails the plain text version is much less readable than the HTML version. It’s possible to grasp the meaning most of the time but sometimes it is just a garbled mess. Aerc has a few features to make this experience less bad. One option is viewing them through a HTML parser/browser (a combination of w3m and dante. This works well for some emails. The generated output is sometimes better than the plain text version of the email

This 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

#128
post #87
post #76

Earlier 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…

> Similar things about other "old tools" from usenet to RSS, just imaging your bank offering an authenticated feed of every transaction, markets changes etc with push notifications as well.

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

#129
post #74

Earlier 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.

Gmail is not a real email client; it lacks basic commands such as mail bouncing. Perhaps worst of all, it has no concept of conversation threads, as I demonstrate here:

https://lwn.net/Articles/837960/

Post reply on HN