Meli – email client in the terminal, in the spirit of mutt | Hacker News Reader

Meli – email client in the terminal, in the spirit of mutt

git.meli.delivery

138 pointsKlasiaster76 comments

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 was thinking was using pine in a unix shell account at university in 2002 and I have the fondest memories! That was an awesome client

People still use (al)pine at the University of Washington, where is was created! They even have stats on it going back a long time: https://staff.washington.edu/corey/pine-stats/

Every email ever sent from anyone working at rsync.net is sent with (al)pine.

Unbelievable that its still in use! But i guess if something works, why stop, right? Thanks for dsharing the stats!

It doesnt just "work".

It's amazing!

The latest version also handles MFA authentication out of the box.

Wow, handles MFA, thats really cool! TIL

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.

Eh wow thanks for then tip (aerc) beeing a user of neomutt i definetly will try that one out.

how to install aerc thanks

From the release tarball:

## Installation

### Binary Packages

Recent versions of aerc are available on:

- [Alpine] - [Arch] - [Debian] - [Fedora] - [macOS through Homebrew]

And likely other platforms.

### From Source

Install the dependencies:

- 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)

Then compile aerc:

    $ make

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.

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/

Why not use procmail for it?

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.

There's functionality for that in meli (`select <query>` command) which then can be used with `moveto` command or `delete` etc...

(Γεια σου Θανάση! μάνος από εμπ και meli dev)

I did that, decades ago. Sieve is a very nice upgrade, safer, easier to read/write, and even had a web UI if you want.

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 could welcome any comparison with aerc (https://aerc-mail.org).

Does aerc support notmuch?

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"

I gotta ask, how do people use this in the real world?

How do attachments and images work?

Does it work with O365? Can I sync my calendars?

Why not just use thunderbird or something?

Genuinely curious

Neomutt user here.

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! :)

Notmuch is fully command line, there are any number of traditional cli commands, it’s a suite ala git but not a tui or anything:

https://notmuchmail.org/doc/latest/

See for example notmuch-search and notmuch-tag.

Maybe you are thinking of notmuch-emacs or some other full blown client. There are many https://notmuchmail.org/frontends/

Notmuch’s core is largely in C and I believe the only serious dependency is Xapian.

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.

Ya use what you like, the more of these tools the better, just setting record straight on notmuch as I use the cli every day via scripts

> Perhaps as it's a text UI, rather than command line.

You must be completely confused with some other tool. notmuch is a command line tool.

Ironically enough (as it's not CLI, merely TUI), I find notmuch interface for emacs to fullfill this criterion.

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:

https://github.com/skx/maildir-tools

Does anyone know the status of gitea federation yet? This is the first repo I've seen in the wild that uses it

But my god this client is beautiful

> 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.

According to this blog post https://a.exozy.me/posts/gitea-actually-joins-the-fediverse/

If this is "in the spirit of mutt", how is it different?

It has context of mailboxes, accounts, doesn't require you to do "tricks" to setup mailbox switching etc.

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.

> my inbox only has 17k mails in it

I can't tell if you're intentionally joking or are actually unaware of that being maybe a little much.

It shouldn’t be. IMAP doesn’t have to download all of them.

Oh, that's fair. I was questioning the reasonableness of having 17k emails but you're right, the software should be able to support it.

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.

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 use two folders, inbox (currently active mails, also sent ones) and trash, which is the ever growing pile of mails.

Most importantly is the use of a mail indexer (notmuch currently) for searching and getting virtual mailbox viewes.

I delete e-mails the moment I don't need them anymore.

Right now, on my main mail, I have ~400 mails in Trash, but only 10 in Inbox and Archive + another dozen in Sent.

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.

It really shouldn't be too much. It's not the 80s.

The same letters slapped into SQLite the most brute way would work (and perform better), so why the embarrassing slowdown?

Is it much? I have around 120k emails in my inbox. macOS Mail.app opens it in a jiffy. Computers are supposed to be fast nowadays.

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.

Hm. I just checked and my ~/Mail/inbox has 1.38 million messages.

That doesn't include most mailing lists, because those are sorted into their own separate folders using procmail.

I use Neomutt with Notmuch, btw. It generally loads in a fraction of a second.

I used to try to keep on top of mail. I don't any more.

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

I am also nostalgic for Pine, but what I think I really miss is the email from 1998, text only messages from my friends and professors.

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. :-)

Any hints at where the name comes from? It means "woman" in Toki Pona.

From the manpage meli(1) :

> NAME > Meli Mail User Agent. meli is the Greek word for honey

https://meli.delivery/documentation.html#meli.1

Hmm, how does this look on a regular 80x25 terminal?

I hope I can use this kind of client one day. The only thing stopping me is my bad English, which results in my reliance on Grammarly etc.

https://github.com/emacs-grammarly try this

I’d like a terminal email client inspired by vim’s usual keys and behaviour. I didn’t particularly like mutt’s default keys.

meli has somewhat vim-like default key bindings. But every shortcut can be re-defined to your own preference. Check out meli.conf(5) manual page!

Good to know, thanks.

The problem is the HTML Emails I annoyingly get sent by non-tech people.

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.

Elinks for rendering html mail and antiword for rendering word documents inside the mutt message view.

meli does pass html messages to w3m by default, but you can change it to anything else with the `html_filter` setting.

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:

https://github.com/jaytaylor/html2text

I think the classic approach is to use something like lynx or w3m with networking disabled, but I wasn't impressed with the output.

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).

I like the compact mode. It looks sleek.

Meli is the Fijian word for mail.

Source: self, Fijian.

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)

Yes, it's an anglicism (english loanword).

For example, a mail ship would be called meli sitima (mail steamer). The postal service is also called meli.

https://en.wikipedia.org/wiki/Royal_Mail_Ship

meli means honey in Greek

love the name

Reply on news.ycombinator.com