I promised to post some minutes from the BOF in $SUBJ here for people who don’t remember all the tool names:
- [l]imit in mutt is very powerful functionality; my other blogpost describes notmuch integration to that
- new mutt-kz has good virtual folder support as notmuch integration; perhaps future of state-of-art text mail clients
- sup is interesting gmail-like text client, but way too slow!
- alot is worth a look as nice notmuch frontend; no screenshots on net though
- notmuch can filter by folder label, so single db is fine for all your folders
- dovecot sync (dsync)
- lookg at images when reading mail remotely – screenenv (set $DISPLAY based on last active screen client), new tool needed for seamless transfer of files back to local machine is needed!
- maildir sync using VCS (bazaar) instead of imap (read mails using “thick client”) (ccxcz)
- prioritization of downloaded mails by using uucp for transfer (lmw)
- sending mails by feeding them to procmail which decides how to send them (ccxcz)
- automatic addressbook building: lbdb (little brother db)
- Trojita is Qt MUA with very fast IMAP.
- another mutt tip: set edit_headers will make mutt not ask about recipient, subject etc. before starting editor, but let you put the headers in instead
If some feature is too slow, you end up conciously avoiding it and losing productivity. This is one of the reasons that we emphasize so much that Git is as fast as it is – you end up using it more because of that. One thing I always found very frustrating was full-text search in mutt; it takes _minutes_ on my mailbox and I end up trying many different header-based queries instead in order to find the mail. But today, I have finally set up notmuch, a very nice and fast mail indexer.
Unfortunately, there was no satisfying way of integrating notmuch with mutt! There is a notmuch-mutt script which creates a temporary maildir with results and moves me there. This was not going to work for me – you cannot make any changes in the “search results list” like deleting mails (I wonder if status would carry if I reply to mails; I suspect not) and in order to get back to your mails, you need to switch mailbox – which implies that your previous position is not restored and that it’s quite slow (few seconds – too much!).
What I envisioned instead was something like the ‘l’imit function that I use very much, just faster. ;-) It turns out that mutt can match message-ids in the limit query and that notmuch can output a list of message-ids of matched mails. Therefore, the most hackish approach is simply to use notmuch to generate a limit specification and perform that – and it turns out that this is good enough (in my scenario)!
Just put these two bindings (or only the first one) in your .muttrc:
# 'L' performs a notmuch query, showing only the results
macro index L "<enter-command>unset wait_key<enter><shell-escape>read -p 'notmuch query: ' x; echo \$x >~/.cache/mutt_terms<enter><limit>~i \"\`notmuch search --output=messages \$(cat ~/.cache/mutt_terms) | head -n 600 | perl -le '@a=<>;chomp@a;s/\^id:// for@a;$,=\"|\";print@a'\`\"<enter>" "show only messages matching a notmuch pattern"
# 'a' shows all messages again (supersedes default <alias> binding)
macro index a "<limit>all\n" "show all messages (undo limit)"
Perhaps sometime in the future, we will get native libnotmuch support in mutt, but I think this is a pretty good substitute for now. :-)
- the way this snippet prompts using a temporary file is completely absurd; mutt needs to get a builtin prompt function for its macros
- only the most recent 600 search hits are shown, since…
- …the filtering is grossly inefficient; it is still very fast on my computer, but if mutt could just directly get a list of message ids and match them, things would be much nicer than me abusing the regex matching machinery
- the 600 search hits limit is global over all folders, therefore if you have a lot of mails and a lot of folders, searching for a common word may hide even some recent results
- notmuch cannot search for substrings, apparently, only whole words
- notmuch does not deal with diacritics and other locale transliteration character classes