As someone who has spent a little time making a terminal-based mind mapper I am really happy to see more people working on fresh TUI tools :] I believe more people should make their own tools to suit their specific needs, particularly when it comes to tooling that is critical for personal productivity.
Can you explain a bit more about your motivation/goals/vision for building this? It sounds really interesting, but after reading the homepage I got a lot of the what and how, but not a lot of the why.
I think it would also be interesting to compare and contrast with existing terminal mail apps, so people can have a frame for understanding it.
I used to use mutt, and after that neomutt. I was following the project when they started some internal redesigns, and I found the process really painful. mutt came out on 1995! It evolved along with modern e-mail workflow. I believe that now that we know the pains of e-mail better we can make it easier for ourselves.
I can only compare other clients to the project’s goals, since as I mention in the post while the foundations are pretty much built, extensibility, scriptability and co. aren’t ready yet.
Some stuff I can come up with now:
mutt has an archaic configuration system, and also almost no one uses it without tweaking it. Sensible defaults are important.
mutt is written in C, and good error management along with Rust’s memory safety can be a huge UX upgrade
mutt does not support plugins at a level comparable to eg (neo)vim.
mutt doesn’t cater to different e-mail workflows, some people might want to use it like a gmail account, some people want full customisation (power users), some deal with mailing lists and development through e-mail.
emacs clients require emacs that not everyone uses. That’s the only drawback I can think of without trying them
As far as meli goes, it is not feature rich or even have beta/stable status like the other clients. Personally I feel like I shouldn’t have published it yet, but I have put it off for 2 years and I might never do it if not now.
Another problem with mutt (which I love and use daily): it’s entirely synchronous, so if you reload mails on a weak connection or open an attachment the client is unusable until the task is done. A modern client (especially given rust’s safe concurrency abilities) would hopefully do such tasks in a background thread!
That’s how it’s done in meli. Threading is still done synchronously because threads span across account folders and I haven’t put an account’s thread structure under a mutex yet.
mutt has an archaic configuration system, and also almost no one uses
it without tweaking it. Sensible defaults are important.
An archaic plain text file is the best configuration system I can
currently think of.
mutt is written in C, and good error management along with Rust’s
memory safety can be a huge UX upgrade
-d was good enough for me.
mutt does not support plugins at a level comparable to eg (neo)vim.
There are hooks you can attach your commands to.
mutt doesn’t cater to different e-mail workflows, some people might
want to use it like a gmail account, some people want full customisation
(power users), some deal with mailing lists and development through
e-mail.
In my case mutt works well to hande multiple maildirs and mailing lists.
As far as meli goes, it is not feature rich or even have beta/stable
status like the other clients. Personally I feel like I shouldn’t have
published it yet, but I have put it off for 2 years and I might never do
it if not now.
Thanks for doing this!
An archaic plain text file is the best configuration system I can currently think of.
Indeed! meli uses a plain text file with keys and values. The archaic epithet was directed to its format; I currently use toml instead of cooking up my own to keep the configuration less alien for some users. toml has support for a few types like tables (hashmaps), arrays, inline tables and doesn’t require extra effort from meli’s side to maintain other than parsing.
There are hooks you can attach your commands to.
I plan on putting hooks too. What I had in mind is an API that lets plugins manipulate the UI, eg an NNTP plugin that creates its own tab for viewing newsgroups.
In my case mutt works well to hande multiple maildirs and mailing lists.
It does, but it doesn’t provide workflows. For example, I plan on integrating mailing lists to accounts, with list archive search, patch handling, auto-archiving of old e-mails. I want to make catching up on high volume lists easier with smart filtering and tagging, if supported.
Thanks for doing this!
Thank you too for your kind comment. It’s only a hobby project but I really want to make it worthy.
All I want is a terminal mail client that doesn’t assume it’s still an era when my mail all lives in a single spool on the PDP down the hall. By which I mean one that doesn’t pedantically lecture me on “well, this is an MUA, not an MTA”, and just, you know, actually does the things a GUI mail client would do. Like understanding IMAP.
I tried mutt a while back and the thing that held me back was it’s lack of simple support for rendering in a browser. Meli should have a one-button escape latch to render email in the default browser side-by-side. For the odd graphical newsletter, it’s so important.
Exciting to watch develop two new terminal email clients – meli in Rust, aerc in Go.
As someone who has spent a little time making a terminal-based mind mapper I am really happy to see more people working on fresh TUI tools :] I believe more people should make their own tools to suit their specific needs, particularly when it comes to tooling that is critical for personal productivity.
Wow voidmap looks wonderful! I use vimwiki for that but I would love to try alternatives, thank you for sharing.
Can you explain a bit more about your motivation/goals/vision for building this? It sounds really interesting, but after reading the homepage I got a lot of the what and how, but not a lot of the why.
I think it would also be interesting to compare and contrast with existing terminal mail apps, so people can have a frame for understanding it.
I used to use mutt, and after that neomutt. I was following the project when they started some internal redesigns, and I found the process really painful. mutt came out on 1995! It evolved along with modern e-mail workflow. I believe that now that we know the pains of e-mail better we can make it easier for ourselves.
I can only compare other clients to the project’s goals, since as I mention in the post while the foundations are pretty much built, extensibility, scriptability and co. aren’t ready yet.
Some stuff I can come up with now:
As far as meli goes, it is not feature rich or even have beta/stable status like the other clients. Personally I feel like I shouldn’t have published it yet, but I have put it off for 2 years and I might never do it if not now.
Another problem with mutt (which I love and use daily): it’s entirely synchronous, so if you reload mails on a weak connection or open an attachment the client is unusable until the task is done. A modern client (especially given rust’s safe concurrency abilities) would hopefully do such tasks in a background thread!
That’s how it’s done in meli. Threading is still done synchronously because threads span across account folders and I haven’t put an account’s thread structure under a mutex yet.
Another mutt user here.
Indeed! meli uses a plain text file with keys and values. The archaic epithet was directed to its format; I currently use toml instead of cooking up my own to keep the configuration less alien for some users. toml has support for a few types like tables (hashmaps), arrays, inline tables and doesn’t require extra effort from meli’s side to maintain other than parsing.
I plan on putting hooks too. What I had in mind is an API that lets plugins manipulate the UI, eg an NNTP plugin that creates its own tab for viewing newsgroups.
It does, but it doesn’t provide workflows. For example, I plan on integrating mailing lists to accounts, with list archive search, patch handling, auto-archiving of old e-mails. I want to make catching up on high volume lists easier with smart filtering and tagging, if supported.
Thank you too for your kind comment. It’s only a hobby project but I really want to make it worthy.
Related: https://aerc-mail.org/
Has there been any advances in mail client technology that would warrant another one? Why would I want to use this over existing clients?
All I want is a terminal mail client that doesn’t assume it’s still an era when my mail all lives in a single spool on the PDP down the hall. By which I mean one that doesn’t pedantically lecture me on “well, this is an MUA, not an MTA”, and just, you know, actually does the things a GUI mail client would do. Like understanding IMAP.
I tried mutt a while back and the thing that held me back was it’s lack of simple support for rendering in a browser. Meli should have a one-button escape latch to render email in the default browser side-by-side. For the odd graphical newsletter, it’s so important.
if you mean a graphical browser, meli shows you the shortcut for opening html mails with xdg-open by default when viewing text/html attachments