all repos — site @ cc595087e6bed27d76e2d9017716ceb66b3b046a

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