Aerc: A well-crafted TUI for email

Your are indeed! Many people like myself prefer the lightning fast interaction of keyboard navigation, the mastery of the bindings to improve workflows, and the customization of bindings to create new ones.

Operation via single-character keyboard commands is really fast in TUI emails clients. In principle a GUI client could offer the same, but I haven’t seen one that does to the same degree. A GUI might be “easier”, but is less efficient for the power user.

Another reason that is more idiosyncratic: If you operate your own email server, you can SSH in from everywhere and use a TUI client locally on the server. This saves the transferring/syncing of emails between client-side local storage and the server; everything is just immediately available.

Convenience is valuable, but the sense of coolness is equally important. Perhaps it's all about the feeling.

A constrained environment forces developers to distill to the essence of the problem, thereby possibly understanding it better. It's the old "simple can be harder than complex" attributed to Steve Jobs.

focus, performance on old/low power hardware.

Besides the other reasons already posted, one big one if one runs one's own email server (have done so since circa 1999) is that remote access to email is just an ssh session.

I find neomutt much easier* than a GUI, especially since I can write my emails using vim. But also, since I get a lot of notifications via email, I can do things like bulk-delete by just typing D + [pattern]

*Once configured, which is definitely not easy.

There is a different social contract between GUI and CLI project maintainers and their users. A menu item can be renamed or moved around and the only thing that breaks is the mental model of users who knew precisely where that menu item was; a CLI option, for example, cannot be renamed or removed without breaking someone's automated script.

Given that difference, some people prefer the stability of their tools not changing on them and prefer CLI/terminal work in general. The difference in social contract may not apply specifically to an email client but a given user might be more comfortable in a terminal than in a GUI.

Personally I use a hybrid, or Emacs under X11, witch is arguably a GUI but also text-based and why for me is because of:

- integration :: I can create in a single keypress (bind to org-store-link) a link to be inserted in a note (another single keypress, org-insert-link) to pretty anything, a specific place in a file, a whole file to be open with a specific app, a mail message, ...

- end-user-programming :: meaning I can easily have a function (or a script, outside Emacs, maybe) that when a new electricity bill email arrive to my inbox it add relevant information in the relevant contract note, an agenda info, a "special timer" [1] that check my BeanCount transaction for a relevant entry after a certain date etc. With LITTLE coding an user can get a personal BI without a BI monster and issues of feeding it all the time.

GUIs suffer from not being textual enough, TUIs due to the lack of full graphics abilities.

Desktop computing in a network is the most powerful form of computing we have, and unfortunately it's long lost for a modern mainframe model (cloud+mobile) witch is terribly limited and limiting and most not knowing anything else do not even understand the limit.

[1] a function that run at a date, and get re-created when a session restart to avoid loosing the timer after a reboot

Personal preference. Perks include consistency and hackability. Mutt for instance hasn't changed a whole lot in decades. The relative simplicity and stability also means I'm not running into a whole lot of bugs. GUI email clients on the other hand...

Resource usage is also about as low as you can get.

Why would you want to use a cartoonish GUI for a text application like email when using a terminal interface is so much easier?

Really short answer: Because the GUIs for mail SW are just not that great. It's been a long time since I used something like Thunderbird, but for the webmails I use, as well as Outlook at work - both tend to have inferior UIs than a good TUI.[1]

Another short answer: A lot of people prefer to use the keyboard. While it's true you can do a lot of keyboard navigation in some GUIs, but they still tend to be inferior to what you can do in a GUI.

Another answer: Performance. GUIs in general are laggy.

Another answer: What are my choices for GUIs for local mail? I always store mail locally on my PC and use a mail SW to interact with them.

Fundamentally, GUI developers optimize for different things compared to TUI developers.

Finally:

but why would you want to use a terminal interface when a GUI is so much easier?

I think you'll find that the HN crowd values a few things higher than "ease". Yes, GUIs tend to be easier. Just like using IFTT is easier than writing code. Yet, many people prefer to write code.

[1] I mean OK, perhaps for a thing or two they're better, but not overall.

You will find no logical answer, it's a religious issue at this point.

I'm guessing that the text interface is nicer if your use case is reading mostly text-based emails from newsletters or forums. But yeah, for general email use I don't see this as a plus unless you really like TUIs.

I'm interested in the Gmail integration. Tried it with mutt and decided I didn't want to spend an afternoon figuring it out.

'Sides, I hear that Gmail is phasing out IMAP. :-?

I'm interested, specifically with the vim keybindings, which would make getting started with it much easier for me.

If someone is interested, I will link my GitHub repo.

I'm very interested...this post has encouraged me to play with aerc again, and the first filter you posted is something I have always wanted in an email client!

https://github.com/rafo/aerc-vim

- Added image preview of attachments

I dont know when it exactly started but I've heard and use this term at least 15 years. CLI != TUI. TUI is more like a "standard" window (GUI) but all text based.

You've charted an incredibly fortuitous TUI-avoiding path through your HN reading, it pops up constantly. Just in the last year:

https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...

vim and midnight commander are TUI

bash and git are CLI

I've seen TUI used for at least a decade? Things like this used to be just called "GUIs" even when running fully in text-mode back in the DOS days.

IMO "ed" is a CLI (i.e. the primary form of interaction is a command line), and "vi" is a TUI.

It's been in use since at least the late 1980s to early 1990s. I believe it was in the Turbo Pascal for DOS documentation I used back then, as well as Turbo Vision and some other things. I also worked on a TUI library for Euphoria in DOS around that time.

And it means a full-screen Text User Interface, which is quite different from a line-oriented CLI (Command Line Interface). Instead of a command line, you have a full screen interface with menus, dialogs, buttons, checkboxes and radios, listboxes, windows, scrollbars, etc. Just all in text mode using things like the box drawing and shading characters.

So at least 30 years ago. Probably the early 80s, although I'm not sure of that. But that's when some programs started going from CLI or forms-based to actually using that full-screen TUI style.

The earlier forms-based programs were basically just a hard-coded text-mode screen with blank fields that you could fill in the blanks, then hit a key to either submit, escape back out, or use a hotkey to pull up a different form screen. They didn't have the various interface widgets that we got used to with the TUIs and later GUIs.

You can configure aerc to pass the email contents through an intermediate program depending on the MIME type. I believe it renders HTML through w3m by default or something like that. Of course it isn't full rendering with CSS and whatnot, but it is pretty good for most mails.

Emacs (even on the TTY), can do a decent job of rendering markup using it's built in EWW browser. Works pretty well, at least for most of the content I'm looking for.

Using it with Notmuch or mu4e is not the easiest thing to do, but it works pretty solidly.

Rendering HTML emails is fine, IMO, unless you want images. (I use mutt with w3m auto-view.) What’s more difficult is authoring/replying to HTML emails.

I use lynx to render html email. Other people use w3m. It's your choice and it's a solved problem.

mutt is alive and well, it's all I use for email.

At work I'm forced to use the unusable gmail website, ugh.

I miss Pine too. I could read/file/delete scores of plaintext emails in seconds using single keystrokes.

Every email client I've used since Pine has been better at dealing with all the stuff we've bolted on to email (HTML, attachments, calendar invites...) but none of them have been as efficient at the core tasks of email as Pine was.

You can parse html emails with it by piping to w3m or using pandoc

Pine is not dead for me yet. I use alpine as daily driver, although the releases are not that often.

I used to use mutt and bind a keyboard shortcut to pipe HTML messages to w3m.

You could give my email client https://github.com/d99kris/nmail a shot. It does basic html email parsing (leveraging w3m and pandoc) and its user interface is inspired by pine.

Maybe dodo[1] is something for you. It is basically a graphical email client but with lots of vim-bindings.

Basically the best of both worlds, terminal and graphical. Like the qutebrowser[2] for emails.

However I think its kinda in a unmaintained state and only supports notmuch backend.

1: https://github.com/akissinger/dodo 2: https://qutebrowser.org/

despite the questionable politics of the author, I use mutt-wizard, and using its configs, a simple "v" instead of "o" will open the mail in the open web-browser. I've found this more than acceptable for reading html mail.

I don't use it for work, only personal use, though, so ymmv.

All fair points. The second and third one can be mitigated by a, say, w3m mailcap entry respectively muttrc entry set send_multipart_alternative_filter=markdown2html.py [1]

[1] https://gitlab.com/muttmua/mutt/-/blob/master/contrib/markdo...

"Mutt/aerc doesn't support windows, an OS many use by preference or requirement"

All modern Windows boxes have Hyper-V built in to some extent and you can run a Linux VM. You have OpenSSH natively too. It will take a bit of twiddling to setup a suitable environment but not much.

I use Linux exclusively and prefer GUIs too. I use Evolution against MS Exchange on-prem, for my sins. I also run a set of vanity email domains for friends and family (Dovecot, Exim etc).

I'm not familiar with Betterbird but it is now bookmarked and noted for eval.

One day we are going to have to dump the Exchange box and I look forward to the discussion about what happens next. M365? Nope, or OK - you kids do that and I'll bugger off and do my own thing. Do bear in mind that I've been running the email system for 25+ years (it was GroupWise once) and I am the Managing Director!

In the end you really can replace Exchange with and IMAPD, MTA etc and a calendaring app of some sort.

Anyway, I'm strolling rather rapidly off topic. Sorry and thanks for the Betterbird notes.

Aerc:

Could probably be built on Windows. You just need Go and make. Betterbird supports MacOS only since a view weeks. My initial suggestions to build it for Mac was denied by the author because of „money“.

Let’s you view html emails. It’s in the article.

I bet moving mails by keystrokes are much faster than drag and drop per mouse. If you use the same folders again and again it even faster. Eg:

  pa = :archive flat<Enter> # move (think put or paste) mail in the archive folder
  pb = :move<space> Brain<Enter> # move mail in my Brain.
  pf = :move<space> # move (think put or paste) mail in folder. Next character filters folders.

Works fine with OAUTH

BB is fine but I hate it that I can’t use my own keyboard shortcuts. A ubiquitous phenomenon.

Also have trouble with shortcut overlapping in neovim and aerc.

I'm curious what you mean by this. Doesn't Vim use almost every key on the keyboard, so wouldn't this be a problem with pretty much any program?

aerc is really weird in the sense of being designed as a client, not storing the mails on your computer.

Isn't that true for mutt as well?

Given the above I'm really surprised that IMAP doesn't work better than it does. Often gets disconnected and I have to restart to get back to it.

Same happens to me. This is gonna sound scuffed, but I just started running aerc in a while loop and I hit q to quit if it's acting up, only takes a couple seconds to load back up. Still my favorite mail client, but could definitely be better.

The best email user agent, mutt, reconnects automatically if the connection to your IMAP server fails (although this seems not to work every time):

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

Using it with local mail dirs is definitely preferable. I would assume that most people use mail TUIs in conjunction with `mbsync`, `notmuch`, and similar utilities that improve the overall experience.

Any particular reason?

For anyone else wondering, it is written in Go.

The original aerc prototype was written in C. It wasn't great.

https://git.sr.ht/~sircmpwn/aerc-legacy

Go it's ideal to replace old C/C++ based utilitarian software such as mail clients, music players and so on. For gaming and high performance needing tools such as the ffmpeg codecs and qemu, C/C++ have more sense there.

so I have been setting up aerc this week, using the Notmuch backend

I strongly urge people to try notmuch. I switched to it in around 2011 and have never gone back.

You don't have to use Emacs as the client. There are plenty of other frontends (including aerc).

https://notmuchmail.org/frontends/

alot[1] is probably the most well known among them:

https://github.com/pazz/alot

If you are using Notmuch, I recommend trying bower[1]. It is a TUI for interacting with notmuch, and can even be configured to do so over ssh, so that e.g. opening attachments can happen on your local machine, even if your notmuch db is on a different computer.

1: https://github.com/wangp/bower

In Outlook, adding a folder to "favorites" creates another reference to the folder in the favorites list; it doesn't change the all-folders view under the account.

Gnome Evolution definitely supports modifying the folder sort order. There is an "Edit sort order" option in the "Folder" menu.

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 great email is when used as originally intended. I'd despise email too if I believed gmail is email, but it's not.

procmail and mutt still work just fine!

Assuming by org you mean an employer - this is also a benefit. For legal reasons, you may not want to have a copy of any of those emails anymore, or at least your employer may not want you to.

I try to forward important e-mails to myself if I think I'll need them outside of work (insurance details, etc).

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.

Composability is what I love about Notmuch: https://notmuchmail.org/

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.

https://en.wikipedia.org/wiki/Text-based_user_interface

Terminal User Interface or Text-based User Interface

I feel the same. I have "only" about 15 years worth of mail in Thunderbird but I am getting increasingly tired of working with the GUI, at least for reading and searching historical mail.

One of these days I will convert my mbox mail to Maildir and try out notmuch.

I see this a bit differently. It’s exactly because some tasks feel like a chore that I gravitate to tools that improve the experience.

To me, keeping these tasks separate is just reinforcing the negative association those tasks have built up over time in my brain. The degree to which they continue sucking has as much to do with my own thinking about the tasks as the tasks themselves. I’d rather find ways to make the suckiest tasks even a tiny bit more palatable, and at least in my case, don’t find that this impacts the things I love about working in the terminal in any way.

At the end of the day, I’m going to have to tackle all of it eventually. Might as well make it easier on myself. YMMV.

This is enlightening. I prefer to lean heavily on my terminal for most things, but tui email + web browsing never quite "clicked" for me. And I feel like this perfectly encapsulates why. Thanks for putting words to the feeling!

Aerc lets you do this, although it doesn't automatically fill it in based on the recipient in a reply. So you have to remember to adjust the sender for each email that you send.

It already supports it and has for years.

aerc is completely themable through what they call "style sets": https://man.sr.ht/~rjarry/aerc/configurations/stylesets.md

The official site has video of it in use.

https://aerc-mail.org/

I haven't given alot much attention yet, but one feature that sets aerc apart is its focus on git-email workflow. Viewing, applying and sending patches is much easier with aerc. Remember that the author of aerc (Drew Devault) is also the developer of sourcehut.