My very first email account (when starting university in the early 90s) was via Pine on a unix machine; and i loved it! Sure, the excitement of "a new tech thing" was there, but also the fast, productive simplicity of it all: i can send a message to someone anywhere in the world quite easily! Years later when i started getting into linux as my personal machine/daily driver, i tried using mutt. Mutt didn't stick for me then. I give mutt (and other terminal clients like it) tons of respect, but for me it has been more an issue on my preference side; and nothing against mutt. And, now over the years (with linux very much my daily driver for years now), I find myself leveraging the terminal much much more - e.g. reading RSS feed via newsboat, etc....sort of a return to the basics, but basics that enable me to be far more productive. But one of the areas where i still can't seem to be comfortable in the terminal anymore is email. I think its because of attachments that i constantly need send and receive, and maybe the workflow for that is not ideal *for me* - i don't know. Or, maybe I've gotten so used to Thunderbird, that my brain seems happy there, where it has been happy in the terminak for other areas - who knows. In any case, i welcome more terminal apps! Yes, keep on improving mutt for others, but maybe this new one might work for me (and others who haven't clicked with mutt and its ilk). Kudos and good luck to the makers of Meli! (Who knows, maybe i'll give it a spin)
I agree Pine was a cute little program, and it served many people well at the time.
But the most important functions for me today in an email client are 1. fast search and 2. auto-complete of contacts and Pine/Alpine was lacking there.
(Gmail has great search but its UX overall is lacking - I find it confusing in many ways and it suppresses important information (e.g. headers, sometimes even an e-mail's subject line). It would be nice to have a non-cloud email client with such a fast search.)
I find notmuch search works fater for me than Gmail’s did (no network round trip). It’s maybe a bit dumber, but that does not matter too much in practice. meli seems to work with notmuch.
Love the recent efforts on building new terminal clients. I'm excited to try meli out. I've been using https://aerc-mail.org/ as a daily driver for several months, but excited to try some others in this space. I found mutt a bit intimidating to configure, where aerc and meli seem more straightforward.
Thanks for recommending aerc. I gave it a try for my Postgres contributions workflow, and it was very easy to use it. Having tried mutt, it was surprisingly easy to configure aerc to work with GMail.
I am able to induce a crash pretty reliably (by pressing J or K at a fast rate), and probably there are other minor bugs hidden. But aerc is good enough to be my daily driver for my workflow.
- go (>=1.16) (Go versions are supported until their end-of-life; support for
older versions may be dropped at any time due to incompatibilities or newer
required language features.)
- [scdoc](https://git.sr.ht/~sircmpwn/scdoc)
With (al)pine in contrast to mutt you at least have filtering rules to move a mail to a folder. I hope that this would be added to meli, too - that's the last thing I would consider missing when reading the docs on the website: https://meli.delivery/
I'm not sure what you mean by this. Most people who use mutt typically use something like notmuch, mailfilter, procmail or imapfilter to implement rules that automatically move certain mail into certain folders.
For doing a move of multiple messages into a folder on an ad-hoc basis in the mutt UI, you select your messages however you want (eg using a regex over subject or sender or whatever) and use semicolon to modify your move command to mean "move all selected" rather than just "move this message".
I'm not the grandparent poster, but I'm not sure if this is what they had in mind by "filtering rules". When I read the comment, I immediately thought of how I use procmail for live sorting of incoming mail, but I also occasionally pull out al(pine) for various manual sorting/rearranging tasks. I've always found its "broaden/narrow selection + zoom" tools to be pretty powerful. (Maybe mutt has tools of similar capability; I don't know.)
Not exactly the same, but in mutt, there is a simple language which you can use to refer to a subset of the messages in your view. E.g. "~U" will match you unread messages, etc.
You can group tag messages on mutt with any pattern you'd like and then move them. Or, you can limit your view to what you want to move, select some and then move them.
Yes, I'm using it with notmuch, and it works reasonably well. A couple of caveats:
- If you want to save outgoing mail, you need to include your own mail-sending script (mine is below). This is because aerc treats the notmuch backend as read-only.
- For the same reason, you can't postpone messages with the notmuch backend.
- I find it a little annoying jumping between search queries. Basically, I have to type out the new query each time. The aerc notmuch backend treats notmuch queries like folders, but it instantly forgets the previous "folder" existed when you go to a new one.
It probably wouldn't be too hard to fix these; if I stick with aerc I'll probably try eventually.
My mail-sending script; tested only on OpenBSD:
#!/bin/sh
#
# Save a copy of an email in Sent, then send it with sendmail.
set -e
TMP=$(mktemp -d)
cat > "$TMP/message"
notmuch insert --folder=Sent < "$TMP/message"
sendmail -f falsifian@falsifian.org "$@" < "$TMP/message"
rm -r -- "$TMP"
Attachments are downloaded with a few keystrokes, I also have a command to "open in browser" if I really really need to see the images which is rare.
I do use mine with Outlook Mail, but it just does mail. I'll bet there's probably a calendar sync thing.
And the why is speed, overwhelmingly. I don't delete any email and I don't have to use spam filters because it's THAT FAST. I can "move" literally as quickly as it takes to identify the message and decide what to do with it (read, not-read and skip, respond etc)
I just archive EVERYTHING that's read, and make a separate note in my todos if there's something I need to act on that isn't a reply. Replying to humans is very quick too, which is really the only thing I need from email.
Attachments: you can open them with any command or save them as a file. For example on linux, you can open a file with `xdg-open` and it will try to select the default app from the mime type.
Images: you can select to view HTML emails on the browser (default is plain text generated by w3m) but it should be possible to use some other script instead of w3m that shows images in your terminal.
No calendar support, it's just email (well, and NNTP)
WHy not use thunderbird? Hm it's personal taste. Since I'm on the terminal most of the time, I find it more convenient. But obviously Thunderbird is the best GUI client since it's most mature, stable and it's open source.
I get excited when I hear of something like this, but then it often turns to indifference when "terminal" UI is shoe-horning GUI elements into large grids of UTF8. There's a time and place for GUI if that is the motivation, and for anything short of that my Pine/Alpine familiarity is going to be hard to beat.
But what would be interesting is "command-line" for a modern email client. Similar in spirit to the old mh, perhaps. Concise commands for viewing folders, threads, searching, composing etc. Which integrate well with grep, xargs etc. for bulk operations.
Rather than IMAP support, the heavy lifting of sync'ing Maildir folders could be done by dovecot, with searches by mairix.
You're probably looking for notmuch, which integrates very well with other tools. There's also mblaze (https://github.com/leahneukirchen/mblaze) that might be of interest.
I heard of notmuch, but I remember I dismissed it for whatever reason. Perhaps as it's a text UI, rather than command line.
However, mblaze looks very promising. Thanks for that. It's almost literally what I had in my minds eye. It's light on dependencies and also packaged for Alpine Linux which is a good sign, and means I'm already trying it! :)
Don't panic, I was just confused as I followed the "Screenshots" link and was presented with a bunch of interactive views in Emacs. But still, I've encountered this before.
Back in the day I wrote my own console based mail-client, scriptable with lua. It worked really well for my needs.
I did dabble afterwards with some simple utilities for scripting mail, showing a list of folders, showing a list of messages in a folder, or viewing a single mail.
After spending so long working on my own client I could never be enthusiastic enough to really take it much further, but for reference the tools still work, against a local Maildir hierarchy:
> And since I get asked this a ton, these federated features like federated following are (obviously) not in Gitea right now, but will probably be released in Gitea 1.18 in October.
Tried this, it sat for 12 hours on "loading..." without success even though my inbox only has 17k mails in it. Given that neomutt is working fine, it's not a huge problem but it's always nice to have options.
Try using the latest commit if you're not already since the last tagged release had a lot of bugs that have been solved. Otherwise, could you file a bug in the issue tracker? https://git.meli.delivery/meli/meli/issues
What are you doing with your old emails? Do you delete them? Or have you found a method to archive them that produces few folders with few emails in each and that works consistently over the decades?
Because I haven't, and having everything in one folder works just fine with the clients I use.
I sometimes wish to find emails that I couldn't have known I would need again.
Right now, I've been looking for the email address of the landlord of the house I lived in until 2009. I'm happy that I didn't remove his email saying that his son would come on Friday to fix the door handle.
Oh, it's a nonsense, definitely, but it only gets cleaned out every 6 months or thereabouts and I've not yet translated the rules in my cleaning script to Sieve rules to do it automatically.
I have 93,000 emails in my mail spool, and it opens in Pine in about 30 seconds on a 1 GHz AlphaServer, even when lots of other stuff is running at the same time.
Nostal;gia for sure! But, there's also something to what you noted about "text only messages"...it feels like folks on email used to be far more - i dont know if this is the right word, but - efficient in trying to get to their point (without depoending on imagery too much). And, i'm not talkiing about usimng shorthand (like BTW, BRB, etc.)...No, i feel like folks knew how to actually craft a short but effective message (for the most part), and emoji were mostly decorative and not part of the core message....but maybe i'm just a grumpy guy remembering thisngs with rose-tinted memories. :-)
I use aerc, which is similar to this, but written in Go. Most of these TUI mail clients have a configurable filter option for different MIME types. I've found that this program does a great job as an HTML to text filter:
With mutt, you can tell it to pass HTML through an external program (like a text mode browser) to render to plain text. Not immediately obvious if meli supports that, but it is at least tractable.
In Mutt I auto-view those with w3m. The main limitation is that you can’t reply while preserving the HTML (at least I know of no TUI HTML mail editor).
Super interesting! I chose meli as a name because it sounds like mail, kinda. Do you know if the Fiji word is a loanword from european languages? (old french/german)
