<- back
view in plain-text

Introducing mael

An experimental mail client

Update: The code lives here: https://github.com/icyphox/mael

I’ve been on the lookout for a good terminal-based email client since forever, and I’ve tried almost all of them. The one I use right now sucks a little less—aerc. I have some gripes with it though, like the problem with outgoing emails not getting copied to the Sent folder, and instead erroring out with a cryptic EOF—that’s literally all it says. I’ve tried mutt, but I find it a little excessive. It feels like the weechat of email—to many features that you’ll probably never use.

I need something clean and simple, less bloated (for the lack of a better term). This is what motivated me to try writing my own. The result of this (and not to mention, being holed up at home with nothing better to do), is mael.1

mael isn’t like your usual TUI clients. I envision this to turn out similar to mailx—a prompt-based UI. The reason behind this UX decision is simple: it’s easier for me to write. :)

Speaking of writing it, it’s being written in a mix of Python and bash. Why? Because Python’s email and mailbox modules are fantastic, and I don’t think I want to parse Maildirs in bash. “But why not pure Python?” Well, I’m going to be shelling out a lot (more on this in a bit), and writing interactive UIs in bash is a lot more intuitive, thanks to some of the nifty features that later versions of bash have—read, mapfile etc.

The reason I’m shelling out is because two key components to this client, that I haven’t yet talked about—mbsync and msmtp are in use, for IMAP and SMTP respectively. And mbsync uses the Maildir format, which is why I’m relying on Python’s mailbox package. Why is this in the standard library anyway?!

The architecture of the client is pretty interesting (and possibly very stupid), but here’s what happens:

  • UI and prompt stuff in bash
  • emails are read using less
  • email templates (RFC 2822) are parsed and generated in Python
  • this is sent to bash in STDOUT, like
msg="$(./mael-parser "$maildir_message_path")"

These kind of one-way (bash -> Python) calls are what drive the entire process. I’m not sure what to think of it. Perhaps I might just give up and write the entire thing in Python. Or…I might just scrap this entirely and just shut up and use aerc. I don’t know yet. The code does seem to be growing in size rapidly. It’s about ~350 LOC in two days of writing (Python + bash). New problems arise every now and then and it’s pretty hard to keep track of all of this. It’ll be cool when it’s all done though (I think).

If only things just worked.

  1. I have yet to open source it; this post will be updated with a link to it when I do. 

Questions or comments? Send an email to ~icyphox/x@lists.sr.ht—my public inbox.

The Beirut Explosion – Is It A Bird? Is It A Plane? Is It A Faked Video Of A Missile?

In the days after every catastrophe, it is inevitable that rumours and misinformation will be passed around on social networks and by word of mouth. This appears to be a universal human behaviour. The disaster in Beirut is no different. In the three days s…

via bellingcat on Aug 07, 2020

pkg.go.dev is more concerned with Google's interests than good engineering

pkg.go.dev sucks. It’s certainly prettier than godoc.org, but under the covers, it’s a failure of engineering characteristic of the Google approach. Go is a pretty good programming language. I have long held that this is not attributable to Google’s stewa…

via Drew DeVault's Blog on Aug 01, 2020

Gripes With Go

You’ve read a lot of posts about the shortcomings of the Go programming language, so what’s one more. Lack of sum types Type assertions Date and Time Statements over Expressions Erroring out on unused variables Error handling Lack of Sum types A “Sum” ty…

via nerdypepper's μblog on Aug 01, 2020

Generated by openring.py






Some of my friends and internet bros.


More about me and my work.