Banner Image

1 E-Mail

I have strattled the terminal and GUI for e-mail for a while now. About two years ago, I think, I simplified my emacs dotfiles by migrating away from gnus and erc (I think I have written about this before in previous posts). Moving from erc to irssi was easy. And though leaving gnus significantly improved the performance of emacs on my machine and reduced the size of my config, I never finished migrating to mutt.

So, I want to point out that there seems to be a bit of trash talking with some of the extended email community for projects listed or not listed below. I don't want to have anything to do with any of that. I just want something that works. And I'm not going to put down anyone as a person. So if someone wrote some code I have linked to either here or in previous posts, it was not my intention to direct anyone to any kind of drama. Please accept my apology in advance.

In addition to that, some terminology in some of these tools definitely falls into the deprecated language category, even pre-2020 for folks who were living under a rock. Again, please accept my apology in advance.

That said, I have my eyes on the following projects and tutorials right now.

Jonathan Hodgson's mutt setup post is probably one of the best I've read, and defintely better than anything I've blogged about. On debian, just to list those packages I do this:


      apt list abook isync msmtp mutt neomutt notmuch

1.1 aerc

Over all, Drew Devault's aerc seems like the most exciting project, though I don't yet feel ready to migrate to it from mutt. Explicit support for managing patches within email sounds like an awesome idea, especially for some folks I know personally who have an aversion to using git. I'm currently waiting for a few more features, such as notmuch added with the new-account step.

1.2 What I really want it to do

That said, what I want, is to either be able to procedurally configure the mail client or save the majority of that configuration in my dotfiles. I want as little manual steps as possible. If I could keep a template config file with masks for PII that are non-secrets (such as my exact mail host or the directory structure) that I replace with a value from pass, that seems like a win.

I have a lot of email accounts, so I can't have a small static limit like with mutt-wizard.

I have an older version my my mutt dotfiles shared on notabug (called dotmuttfiles). That allowed sourcing a new file depending on a quickly hacked together shell script to pick the next account. Personally, I'd rather not mutate the state of mutt like that. In newer versions, I've removed that feature and I've introduced some secrets/PII, though, so that version has gone stale. I've updated my dotfiles with a template for mutt and mybsync for now. It has minimal configuration values, with a couple of exceptions just in case different versions have different values. I also added a stub muttrc so running as the system user remains the default. For now I have just one mbsync dotfile and one muttrc for each account. Then I just do something like this:


      mbsync foo-inbox
      mutt -F ~/.mutt/muttrc_my_foo_account

2 Emacs dotfiles

I have a few known issues with my emacs dotfiles. Some commands only work in the windowed emacs such as iedit's default section command C-; or anything I use with the super key. Some packages break when running a different env (ispell). Of course, some of these might work fine in a newer version of emacs.

3 Reading