all repos — site @ 04f3b4a38379e78d252794d426d45782c3215834

source for my site, found at icyphox.sh

pages/txt/mael.txt (view raw)

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