Mutt 1.7.0 released | Hacker News Reader

Mutt 1.7.0 released

marc.info

105 pointstdurden90 comments

Many people try to switch to Mutt thinking it will be like using gmail but in the terminal. It is not.

Mutt is a productivity tool, like vim and emacs, but for email instead of code. You need to invest a lot of time into learning it, refining your configuration, and getting comfortable with its interface. It will originally be as frustrating as giving emacs to a notepad user, but eventually pays off the learning cost in productivity.

Some examples of commands I use all the time:

* shift+D deletes an entire thread. Very useful to delete entire github discussions in one command.

* `t` flags a message, then `;+s` moves the entire flag to another folder

* custom macros. For example, I use `short+C` to move the message under the cursor to folder `foo`. I have 5/6 similar macros for the folders I use most.

GnuPG integration is also a big help (I use it constantly). I'm use many other MUA offer similar shortcuts and configurability, but Mutt is the fastest and most flexible by far. The one thing that I haven't found a good solution for is full text search across multiple folders. I still rely on gmail for that.

> shift+D deletes an entire thread. Very useful to delete entire github discussions in one command.

If you enable keyboard shortcuts from Gmail's settings screen, "e" archives the entire thread and moves you back to the inbox. "m" will additionally mute the thread so new replies don't show up in the inbox. You can also use "{" or "}" to archive and move to the next or previous thread, instead of back to the inbox.

> `t` flags a message, then `;+s` moves the entire flag to another folder

"x" selects the current thread and moves you back to the inbox. Then "v" brings up the menu for typing which folder to move all selected conversations into.

> custom macros. For example, I use `short+C` to move the message under the cursor to folder `foo`. I have 5/6 similar macros for the folders I use most.

"vfoo" will do that.

Gmail is also a productivity tool, and you should also invest time into learning it and getting comfortable with its interface.

Mutt is a productivity tool that's learned (or at least practiced) the wisdom that you don't fuck with a productivity tool's UI/UX gratuitously.

Google ... hasn't.

> The one thing that I haven't found a good solution for is full text search across multiple folders.

https://notmuchmail.org/ ?

Thanks for stating this, because it's almost comically difficult to find out what Mutt it starting from the above link!

I love the snappiness and power of mutt but when I tried to switch to it as my full-time mail client it didn't end up being an improvement. Not really due to any fault of mutt's but because I disagree with the common POV that HTML email is useless/the scourge of the Internet/etc.

What really ended up being the dealbreaker was that the viewing and authoring experience for moderately marked up text was poor. Specifically: Quoting, bulleted lists, inline attachments, and maybe a few other basic formatting tricks. This kind of stuff doesn't end up rendering well when I view the mail in a terminal-based browser like w3m, and I didn't even try authoring (am I going to hand-code the HTML for every email I write?).

I wish we had something like Markdown for email--to me that would be the sweet spot between the mess HTML email has become, and plain text which sometimes does lack in its ability to communicate information.

Beyond that I would love any advice on how to use a terminal-based mail client but still be able to author and view some kind of useful representation of things like lists and quotes. Maybe with just the right configuration this can be done...

Have been thinking about markdown email support as well. That would solve many of our problems!

I've switched to using Emacs (with mu4e + offlineimap). Composing pretty emails using Orgmode is great. It's even possible to render code snippets with code highlighting taken from your current theme. Attachments handling is pretty great as well. My only problem is rendering of HTML emails is not good. It tries its best, but most of the time it doesn't work (about 50/50 from my experience).

Have you tried an Emacs with eww which relies on libxml2 for HTML parsing?

Have you tried isync (mbsync), instead of offlineimap?

I found offlineimap slow and crashy, and switched to isync.

Yes, offlineimap crashes every few hours. Not a big deal for me (I don't get a lot of emails), but it is annoying. I'll give mbsync a shot.

(mu4e author here)

Mu4e has a few different options for displaying rich-text messages. In recent emacsen, it defaults to a shr/eww based display; it's not perfect, but it reduces the set of problem cases.

For those, there are the view-in-browser action, and with (as of yet unreleased) emacs-25 you can use a webkit-based display embedded in emacs.

With those, I'm able to view just about any message; even the ones I get from airlines etc., which tend to be html-only.

Anyway - to get back to the top-level subject: congratulations to mutt, which is a great e-mail client, and a big influence on mu/mu4e.

I don't use mutt but IIRC a basic feature of both mutt and similar (pine + variants, etc.) is allowing you to define your own external editor. Therefore, there's nothing to stop you adding a wrapping pipeline to that so that, for example, first you edit normally in your preferred editor, and second an established piece of code or basic series of regex replaces your markdown with whatever you actually want. Optionally, the reverse runs before editing. This should not take longer than a few hours on the outside to get running comfortably.

I can't believe I never thought of this! Brilliant idea. Now just to solve the viewing problem...

The reverse should work for simple HTML.

For complex HTML to plain text try https://www.google.com/search?q=lynx+convert+html+text .. most text browsers can do a reasonable job of it.

Using lynx (or elinks, in my case) to view HTML email in mutt is the historical solution. I think the desire here is for a reversible transformation. E.g. I can receive an HTML email, view it as Markdown, reply using Markdown, and then send an HTML email in reply.

Unfortunately, I think foreign email clients would mangle the HTML just enough to stop this from working. You'd have to start implementing a tag soup type parser to coax incoming mail into something intelligible.

We're almost at that stage with HTML already.

I'm thinking that a multi-pass parser:

1. Is this sane HTML5 markup? I'll eat that.

2. Is this a borked-but-manageable variant? Strip the cruft.

3. Is this Beyond All Hope? Just dump it as ASCII. It'll be blockquoted in reply.

HTML is no longer a peresistent, stable, or universal interchange format.

Well you can use pandoc too or w3m.

For some HTML mails, it is sufficient to use a mailcap file in combination with lynx or w3m:

  # ~/.mutt/mailcap
  text/html; w3m -I %{charset} -T text/html; copiousoutput;

  # ~/.muttrc
  alternative_order text/plain text/enriched text/html  # save html for last
  auto_view text/html

If you want the full HTML experience, you can use this script [1], which uses python (there also is an older bash version) to convert the mail into standalone html to be viewed inside a browser.

  # ~/.muttrc
  macro index,pager M "<enter-command>unset resolve<enter><clear-flag>N<enter-command>set resolve<enter><pipe-message>viewhtmlmail\n" "View HTML in browser"

1: https://github.com/akkana/scripts/blob/master/viewhtmlmail

How about using Pandoc[0] as part of your wrapping pipeline? It supports the full round trip between markdown, HTML, and back. Seems like this would be a perfect use case for it.

[0] http://pandoc.org

This is insanely brilliant. I am now happy to use Mutt again.

Yeah, I came here to suggest pandoc too.

You can easily script mutt to include a plaintext file and an html one generated by pandoc, so that people reading your emails can fall back to a plain text version of your mails in case they can't view html.

If you folks have already done the legwork on this, could you please publish your setup?

Yes please! This sounds intriguing. I send plain text only from mutt but including HTML from Markdown via Pandoc would be very cool.

Here is what I use.

  # convert markdown to html via pandoc
  # https://unix.stackexchange.com/questions/108485/send-    email-written-in-markdown-using-mutt
  macro compose \e5 "F pandoc -s -f markdown -t html \ny^T^Utext/html; charset='utf-8'\n"

Thanks!

I think you are solving the wrong problem.

The problem isn't HTML, it is its users. People who can't quote properly, people who end every single sentence with an emoji, etc. In a nutshell, people who have never experienced Usenet never learned how to communicate properly with a keyboard.

The fix for this is to configure your email client to auto-answer a rejection message when it receives anything other than plain text. You can always blame your antivirus for that.

Help people with disabling HTML email. With a little bit of luck, they won't remember how to enable it again. And hopefully, since they won't be distracted any more with fancy formatting, animated smiley and which GIF-meme-to-use-for-this, hopefully they'll focus on words and reinvent ascii art.

Many people use Android Mail which cannot send mail in text/plain if i understand correctly https://code.google.com/p/android/issues/detail?id=8712

Is this kind of condescending, elitist remark destroying one of the few last redeeming qualities of email? That everyone can talk to everyone else outside of walled gardens?

Don't get me wrong, I'm a big fan of plaintext email (and use mutt at work) but it's not practical to expect the world to bend to your own narrow choices in technology so harshly. The attitude displayed here is, quite frankly, disgusting.

That's nice, grandpa. I'm probably physically older than you, but I mostly commonly see your attitude when I'm sipping beer with old vets down at the Elks lodge.

Just because we invented and pioneered the early 'net doesn't mean we own it. Things change and usage patterns evolve as people join and leave the medium. Email today is a medium for HTML and emojis for almost everyone using it, except for the curmudgeons. We don't get to define "communicates properly".

Don't be a curmudgeon. This isn't "our" system anymore, if it ever was at all.

With all due respect: your approach here is to tell a billion people to jump over the Grand Canyon or kiss your ass and die.

My approach is to go as far as I must to meet them halfway because I know I wasn't born perfect either.

Engineers are brilliant in ways that are rare, valuable and admirable. But they don't tend to have a great level of empathy and trust me, it's something worth cultivating.

I see every day people being owned by phishing and malware and their privacy compromised because they are accepting HTMaiL.

I've heard people complaining about email conversations that they can't understand any more because every one used together top-posting, bottom posting, coloured inline replies and no trimming.

I want this madness to end. If it isn't empathy, what is it?

It's no different than telling billion people to stop using Flash or kiss a specific part of my body and rest peacefully. Except perhaps that we are a few anonymous "disgusting elitist curmudgeons" instead of being huge internet companies.

I get the frustration. But I think that war's been lost.

Within a given organisation (if you're exceptionally lucky), or on some mailing lists, you might be able to enforce discipline. At large, though, this mostly doesn't scale.

I think it's unfortunate -- there's a very strong degree to which standards of message formatting are useful and helpful. And, in counterpoint to much of the disagreement to your point, it's not as if a bunch of Unix geeks in the 1970s and 1980s started the concept -- go through any "how to succeed in business without really trying" manual from the 1920s through 1970s, and you'll find strongly specified guides on how you are to type and format your business correspondence (using your monospace Royal, or later, IBM Selectric, typewriter). And deviations from those standards were not appreciated.

But until and unless some Hand of God comes down and enforces discipline again, we're in our current State of Babel.

On the other hand, client quirks are so common now that configuring you email stream to:

1. Render all incoming messages as flat, 72-character, ASCII

2. Outputing messages with same, '> ' quoting, etc., etc., is pretty much perfectly justifiable.

"Oh, my email doesn't handle attachments or binaries, I'm sorry."

If you are in a position to ensure people talk to you on your terms, so much the better. I can approach that, but there are sacrifices to be made.

I'm not a mutt user, but I believe in the power of text. Look at your comment. It's a lot of text, and zero formatting. But still it's powerful at achieving what you want to achieve. I really don't see why you need that kind of html stuff or markdown, or inline attachments, etc.

yeah to hell with those latex documents and word processors, behold the .txt file!

But latex and word are usually for printing a document. For something that will later be printed, you would want some sort of control over the actual look as the appearance is a large part of what is being communicated. Printing is also much more expensive than sending electrons so you would expect a much more developed medium for this.

I have never printed an email in my life. The appearance of the text is not essential to what is being communicated. Here a certain consistency is more important that variety - or rather the variety comes through the vocabulary and written expressions, not the font shape.

The same could be said for IM clients or IRC. Except for a few minor tweaks such as html links there is no real need for text formatting in these mediums, and very few clients even make the effort to do this.

Go ahead and write Markdown. Every one of your recipients will understand, as Markdown is essentially taken from how people write plain text email (> for block quotes, * for bulleted lists, _ for emphasis etc.).

I've seen that some graphical clients seem to interpret these characters. It's common for block quotes to be colorized and foldable, for example. (But what do I know? I'm an old fart in email matters.)

I use Markdown Here for this - - compose in Markdown, click a button, get nice html-formatted email.

One annoyance is not being able to get back the original markdown. But a mutt workflow could easily deal with this.

If you are on a Mac, try https://freron.com/. I moved to it from Mutt. It uses Markdown to write emails, has fantastic search capabilities, etc.

Im using markdown for writing email, and then on "send-message" I have macro that converts to html (pandoc), and sends an e-mail.

I agree with you, html mails can be usefull and people like them more than plain text (specially marketing,sales, etc).

I believe I have sweet spot with mutt, lot of custom configs being very productive, but not ignoring html . Sidenote, I use xombrero to view html mails if they are complex (inline images etc) - it is very fast and always shows mails correctly

Am I the only one who wishes Mutt loaded mbox files faster?

A couple of years ago I wrote an mbox parser that was several times faster than Mutt's. It really showed because at the time my server was running on a Soekris net6501, my mailbox was a few hundred megabytes, and my habit is to invoke and exit mutt repeatedly rather than using a dedicated terminal window. Since then I've been running my server on a Xeon E3, and it's less bothersome.

I investigated patching Mutt to use the parser, but it seemed a little too much trouble for the effort given how many one-liners have accreted in the existing implementation. Using an index would make things more responsive, too, but the faster parser could provide competitive responsiveness into the gigabyte territory while keeping things simple, in both code and on the filesystem.

Is this a common enough gripe that it might be accepted and appreciated? My parser used Ragel but I could implement it again in plain C so it didn't have a build-time dependency.

I'd wager any mbox optimization efforts are put on the back burner in lieu of modern usages, which seem to be in favor using it as a IMAP client only.

I'd agree with that.

That said there is an obvious solution to slow MBOX folders, which wouldbe to switch to using Maildir-storage, then using the `header_cache` setting(s).

I personally don't mind MBOX, it's a simple format and if you archive it regularly and don't let it grow exponentially, it can be nice to work with.

mbox is fine for a read-only (or at least append-only) archive. It's when you start deleting messages, changing flags etc. in the middle that it becomes a pain.

For years i used Mutt as an IMAP client, but that was honestly quite a nightmare. Even back in the day at uni with an über fast internet connection it was still just not responsive enough. The day i switched to using OfflineIMAP and a local Maildir it was as if the blinds had been drawn aside and sunshine streamed into my INBOX :).

Having said that, i use mu4e these days, because i've become an Emacs user. With a few tweaks it now scratches my itch very effectively (except of course the HTML-email problem as mentioned elsewhere -- this is especially troublesome at work where they want me to include an HTML-embedded-image-tabled monstrosity with about a page of legalese as a signature).

I hate to make any assumptions about your environment, but surely you can abandon mbox for a modern storage format (e.g. Maildir)?

I can sympathize with the pain of a slow mbox parser, but even a magical parser can't resolve the fundamental flaws in the format.

The common solution is to split your mbox regularly. You can use mairix to search across many mboxes, it creates a new mbox with a certain name that contains the matching mail that you can open with mutt.

Hey,

I'm not sure if it's upstreamed yet, but at least the Red Hat fork includes a patch to use unlocked libc IO which more than doubles the mbox parser performance: https://github.com/karelzak/mutt-kz/commit/0672404fc710b4af5...

Mutt's parser is woeful, it's a decade or so of hacks, and in some cases it can't even round-trip its own mboxes without corruption

Weird, my mailboxes each contain 10K+ emails and load in a snap.

Is there any particular reason you're using mbox rather than maildir (single-message-per-file)?

Mutt offers quite good header/index caching, and there are other tools for improving on that.

This release is particularly interesting because it includes the sidebar patch, which has existed in various forms for about 10 years [1].

Mutt has generally been quite conservative in accepting patches. NeoMutt [2] is a project hoping to kick-start development on the Mutt project, by being much more willing to accept contributor patches.

The repository [3] is becoming more and more active; help is always greatly appreciated!

[1]: http://www.lunar-linux.org/mutt-sidebar/

[2]: http://www.neomutt.org/

[3]: https://github.com/neomutt/neomutt

If you like console-based mail-clients you might want to checkout my own project:

https://github.com/lumail/lumail2/

This is directly inspired by mutt, but uses a real scripting language (lua) for most of the operations. It allows you bind keys to lua-functions and so on.

Oh wow, this is looking really good! What mailboxes do you support?

Only (local) Maildir and (slow) IMAP at the moment.

I want to improve the IMAP, but it's always a low-priority.

First, this looks really cool.

Second, and sorry if I missed it just glancing over the project, is there a way to tweak the views, like with ```message```? (Wondering if I can insert pandoc or the like to change how it displays in the terminal)

Might be best to file a bug-report if you have questions/feature-requests.

But see HACKING.md. In brief the display of mode X comes from the output of the function "X_view()". So you can change the rendered text there by updating that function.

So for changing the message-displayed you'll want to tweak `message_view(msg)`, and can add rendering there.

Hope that helps.

Complete changelog: http://www.mutt.org/doc/UPDATING

"Please watch for airborne bovine."

On the topic of console email clients, why does Mutt receive so much love and Alpine doesn't? I used Pine for many years in college and I really liked its menu interface and its ability to read news.

I used Mutt some years ago and found it too complex for the task. Maybe it's becaused I was used to Pine.

Has somebody used both recently and can elaborate a bit? Thanks!

May be due to Mutt's more Vi-like user interface. Vimmers use Mutt and Emacs guys use emacs-based mail user agents. There aren't too many people preferring terminal mail apps left for Alpine.

Just to be contrary, I happily used emacs and Mutt together for about a decade.

(I wanted to start using Mutt again earlier this year, but so far the labour of love involved in cobbling a good .muttrc together - without just copying bits and pieces from other people's - has proved too much like hard work, and I have enough of that as it is.)

I'm a brain damaged user. I switched from Vim to Emacs a few years ago but kept Mutt. But I also tend to (ab)use Emacs like it's Vim. No emacsclient but I still pop in and out of it quickly. .emacs has a lot of lazy loading to keep startup snappy.

There are actually no emacs mail clients that I could get to work :-(. So I used mutt for a while. Nowadays, I answer all my email on my phone, when I can bother to sort through the deluge of spam at all.

I haven't used Alpine, but did use Pine for a while (also elm, mail, whatever the standard VMS client was, and some others).

I quit using Pine for the usual reason: it was nonfree and not bundled. My first alternative was Netscape Mail (actually fairly decent, threaded, which helped). Then got into mutt.

Mutt is just ... more power-user than Pine, I guess. The ability to tag and pipe messages or headers into shell tools is hugely useful. Wnat to get a summary of messages by sender, subject, or parse bodies on the fly to give some simple stats or graphics? That's doable as a shell one-liner from mutt.

(MH is another option and probably even more amenable to scripting tricks -- see Larry Peeks book on the topic.)

I used to use mutt, but I switched to Thunderbird because I now have to track more than one mail account and like having a clear overview of all my accounts.

I al perfectly aware of the fact that mutt can handle more than one mail account: I used to change settings with chdir hooks and stuff like, but honestly, it's quite an overkill.

One problem I have had with mutt and I don't see it fixed in the current issue relates to GPG support. It appears that when I send an encrypted e-mail, mutt does the obvious thing and saves the encrypted e-mail in my sent folder. But that's encrypted /to the receiver/, not to me. Hasn't this bothered enough people for mutt to fix it, so that GPG-encrypted e-mails are encrypted-to-self when copied to Sent?

There are at least three ways to solve your problem:

1. Use fcc_clear=yes to not encrypt the copy in your sent folder

2. Use GPG's encrypt-to in your GPG configuration: https://www.gnupg.org/gph/en/manual/r1261.html

3. Add --encrypt-to to the GPG commands mutt uses: https://dev.mutt.org/trac/wiki/MuttGuide/UseGPG#TheCodeSourc...

Thank you for (2). (1) is not an option for obvious reasons, but I had been using (3) and it was not working as claimed. I'll try (2).

I'd love to do email in the console, but I have the impression that it just wouldn't work with my corporate email servers

If it works in other email clients, it should work in Mutt. Personally setting up Mutt was easier than most email clients for me.

Exchange's IMAP and SMTP implementations work fine. The only really awkward things I've seen are that IMAP search doesn't quite work and calendar invites don't do the magical thing you want. But it's definitely reasonable to use a text client for most things and pull up OWA for the occasional edge case.

Honestly, it's Gmail I've had more trouble with, because labels aren't really folders as the IMAP spec envisioned.

So, serious question: Why do you use console e-mail?

You didn't ask me, but: Because mutt is a very fast and efficient email program and happens to be a console program, and graphical user interfaces tend to not add anything useful to email if you are communicating with people who know how to use email.

Speed and efficiency. Very convenient keyboard only use. Highly configurable and scriptable. Available from anywhere with ssh.

mutt does many things out of the box that other programs cannot do or just with plugins and/or inconveniently hidden functions. Some examples of things I frequently use:

- bouncing mail

- re-send incoming email (after editing it)

- changing headers of composed emails on the fly

- show (only) certain headers by default

- using your editor of choice for composing mails

Why do you need to frequently change email headers?

Examples:

- Add "Approved:" headers for moderated/closed mailing lists

- Add or remove In-Reply-To headers as needed (remove if I reply to an old mail but it has nothing to do with the thread; add if I reply to a mail from a mailing list that I don't have any more but I have the message ID from an archive)

- Change the From address.

I do most stuff in terminal and wanted to do email as well.

* Keyboard-based interaction.

* Actual macros and extensibility (i use mu4e which isn't strictly a console e-mail client, but it's text-based and allows me to Elisp the crap out of any issue i'm having).

Other reasons I haven't mentioned:

Using Mutt is the easiest way I've found to get and (more importantly) keep GPG configured. Yes, people use it; in my case, for interacting with some open source projects.

I've played with setting up various graphical clients with it, but I don't use GPG every day, and it somehow always manages to break in some annoying way. Configuring that with Mutt is loosely coupled enough that it just keeps working.

And second, once you're comfortable with your config, triaging huge amounts of mail is blazingly fast. You might not notice the delay that comes from the occasionally slow GUI reactions, intentionally slow animations, dialogs, the mouse, etc. But compared to the instant reaction to single character commands, there's no contest, and if you're catching up on an enormous amount of mail for some reason, it really makes a difference.

And if you ever have to deal with automated mail systems that succumb to sudden-onset logorrhea in your direction, regular expressions for tagging mail for group operations are a godsend.

Most importantly: compose your email in $EDITOR.

Secondly, the availability. Having a mosh/ssh connection to your shell service works over the crappiest internet connection you might come across.

And finally, it doesn't change. Every time gmail changes their UI, I hear lots of complaints from people using it. This new mutt release will work with your existing config files and have the same look and feel you're used to.

Mutt is particularly good at tagging and filing email: move down a list, marking things with a single keystroke, then filing them with another couple of keystrokes. Or you can filter by query with regexes. It also has proper tree threading, which is useful for mailing lists.

When working in console just hit mutt

There are some users at my company who do not filter their email into individual folders automatically.

Those tend to be the users who accumulate upwards of 100K messages. At some point, their mail client throws up and stops responding, and they call for help.

I use mutt to load their gigantic inboxes, tag everything in certain date ranges, save those messages to new folders, and leave them with inboxes merely holding messages received since January 1, or in the last 3 months, or whatever makes them happy. This takes about 30 keystrokes.

Then I suggest that they automatically filter messages, and sometimes they take me up on that.

Because everything else works in a terminal, and my own mail client is so very scriptable.

(Sure you can add hooks, and things to mutt, but once you have a mail client with a real integrated programming language it is hard to move back from. Mark all messages read? A single keystroke. Perform operations on messages that are less than 24 hours old, and contain a given token in the subject? Just a short function away.)

for me, vi bindings when I compose mail. Also, it does threading right (multiple levels like reddit or hn, vs. flattened like Facebook)

I don't any more. My current job uses Gmail.

At my last job, I used it partly because it was what I was used to, and partly because I used Linux (for my job) and there aren't any great Exchange clients for Linux. At least with the version of Exchange we ran, you only got OWA "lite" if you weren't on Internet Explorer. And I didn't really want to use Thunderbird or something.

It also has the advantage of being in the same interface that I use for everything else... basically the same reasoning that I use Slack in the browser instead of as a separate app.

The ability to consistently access my email from any device (Linux desktop, non-Linux desktop, Android, iOS, whatever) with the same UI is pretty nice. With Gmail I'm finding that the experience differs a lot based on how I connect.

Finally, console clients are good at passing through emailed patches unharmed (e.g., not converting tabs to spaces), which is useful if you participate on LKML or a small number of other open source fora where the standard way to send patches is through email. You can of course get git to talk directly to your SMTP server, but I like seeing what I'm emailing in my client before I email it.

I'm biased, I wrote my own mail client, here's an example of how flexible a console mail-client can be:

https://asciinema.org/a/chdqz6tb4vt9p3ifp32g4musa

Limiting to folders, showing only today's messages, showing new messages only. That makes reading mail very efficient. Also bonus easter egg.

Does this new release include a sane concept of multiple accounts? Or are we still stuck with hook voodoo?

I haven't seen mentioned:

* Is assigning specific tags to messages (or labels) supported? What's the interface like?

* Any fast searching/indexing options?

* Anything, generally, for improved behavior with Gmail?

And it is already in Debian Testing! Dear maintainer, thank you!

Reply on news.ycombinator.com