Trying Out aerc

Written By: Jake Bauer | Posted: 2020-05-18 | Last Updated: 2020-05-18

aerc is a new terminal-based email client created by Drew DeVault that aims to offer a highly efficient and extensible mail experience. I decided to take a look at it after hearing quite a few good reviews of it and its capabilities in the Fediverse.

I currently use NeoMutt, a fork of Mutt, which is also a powerful, terminal-based email client. However, I’ve found it a little clunky to use at times and the sheer amount of configuration that must be done to make it usable (in my opinion) is crazy. It’s still a perfectly capable email client which has served me well, but my search for simpler, more “minimal”, software has led me to try aerc. (Some other mail clients which I may also try in the future are S-nail and meli.)

To get aerc up and running on my system, I cloned the git repository and checked out the 0.3.0 branch. I installed scdoc and go-1.14 to build the software from source using make install. Upon running aerc with the aerc command, I was presented with a straightforward setup process which got me up and running with my mail account configured.

Most of the controls were immediately intuitive. j and k for scrolling, J and K for switching folders, D for deleting mail, Enter for opening mail, and so on. It also seems like aerc has far better support for multiple email accounts. Using multiple accounts in NeoMutt feels unintuitive and hacky by comparison. Another thing that I really appreciate about aerc is that it puts its configuration files in ~/.config/aerc/ by default instead of dumping them in a folder like ~/.aerc.

Something of note which may be useful to others is that I needed to install dante-client to get the default text/html filter to work because it relies on the socksify command to run w3m sandboxed for viewing HTML emails.

I’ll be playing around with aerc for the next little while to decide if I’m going to fully switch to it from NeoMutt. Expect configuration files to appear in my dotfiles repository and a much more comprehensive look in the future.

This is my twenty-third post for the #100DaysToOffload challenge. You can learn more about this challenge over at