1---
 2template:
 3slug: mael
 4title: Introducing mael
 5subtitle: An experimental mail client
 6date: 2020-03-29
 7---
 8
 9**Update**: The code lives here: https://github.com/icyphox/mael
10
11I've been on the lookout for a good terminal-based email client since
12forever, and I've tried almost all of them. The one I use right now
13sucks a little less -- [aerc](https://git.sr.ht/~sircmpwn/aerc). I have
14some gripes with it though, like the problem with outgoing emails not
15getting copied to the Sent folder, and instead erroring out with
16a cryptic `EOF` -- that's literally all it says.
17I've tried mutt, but I find it a little excessive. It feels like the
18weechat of email -- to many features that you'll probably never use.
19
20I need something clean and simple, less bloated (for the lack of
21a better term). This is what motivated me to try writing my own. The
22result of this (and not to mention, being holed up at home with nothing
23better to do), is **mael**.[^oss]
24
25[^oss]: I have yet to open source it; this post will be updated with
26    a link to it when I do.
27
28mael isn't like your usual TUI clients. I envision this to turn out
29similar to mailx -- a prompt-based UI. The reason behind this UX decision
30is simple: it's easier for me to write. :)
31
32Speaking of writing it, it's being written in a mix of Python and bash.
33Why? Because Python's `email` and `mailbox` modules are fantastic, and
34I don't think I want to parse Maildirs in bash. "But why not pure
35Python?" Well, I'm going to be shelling out a lot (more on this in a bit), 
36and writing interactive UIs in bash is a lot more intuitive, thanks to
37some of the nifty features that later versions of bash have -- `read`,
38`mapfile` etc.
39
40The reason I'm shelling out is because two key components to this
41client, that I haven't yet talked about -- `mbsync` and `msmtp` are in
42use, for IMAP and SMTP respectively. And `mbsync` uses the Maildir
43format, which is why I'm relying on Python's `mailbox` package. Why is
44this in the standard library anyway?!
45
46The architecture of the client is pretty interesting (and possibly very
47stupid), but here's what happens:
48
49- UI and prompt stuff in bash
50- emails are read using `less`
51- email templates (RFC 2822) are parsed and generated in Python
52- this is sent to bash in STDOUT, like
53
54```sh
55msg="$(./mael-parser "$maildir_message_path")"
56```
57
58These kind of one-way (bash -> Python) calls are what drive the entire
59process. I'm not sure what to think of it. Perhaps I might just give up
60and write the entire thing in Python.
61Or...I might just scrap this entirely and just shut up and use aerc.
62I don't know yet. The code does seem to be growing in size rapidly. It's
63about ~350 LOC in two days of writing (Python + bash). New problems
64arise every now and then and it's pretty hard to keep track of all of
65this. It'll be cool when it's all done though (I think).
66
67If only things just worked.