User: Password:
|
|
Subscribe / Log in / New account

A Notmuch mail update

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

By Jonathan Corbet
February 19, 2014
Your editor has, for many years, been in search of a better email client. It is continually surprising — and frustrating — to see how hard it seems to be for our community to do a good job with one of the tools it relies upon most heavily. As part of this search, your editor reviewed Notmuch nearly four years ago. Since the email-client problem has not been solved in the meantime, your editor decided that perhaps Notmuch merited another look.

Shortly after the previous review, Notmuch development appeared to come to something approximating a complete stop after Carl Worth, the creator of the project, got busy with other work. In the last couple of years, though, David Bremner has accepted the challenge of pushing Notmuch forward; in response, a small but dedicated community of developers has come together. Notmuch is, once again, making semi-regular releases and adding new features; the current release is Notmuch 0.17, which came out at the end of December.

Notmuch remains more of a kit from which an email setup can be built than a complete solution in its own right. In particular, it doesn't handle email sending and receiving at all, and its approach to the user interface, while improving, may still feel a bit desultory to anybody who is used to a more polished client. So Notmuch will not be an appropriate solution for anybody who wants a ready-made point-and-click environment. But it may well be the right solution for users who deal with large amounts of mail and are willing to put some time into creating an optimal setup.

At its core, Notmuch is a command-line tool that manages a searchable index for a local mail repository. The mail itself must be stored in the filesystem, one message per file; the Maildir and MH formats both work. The local storage requirement has been a show-stopper for your editor in the past; there are real advantages to having one's email behind an IMAP server in a central location. It's nice to be able to access email from multiple machines, including tablets and handsets. For users who live their lives out of their laptops, perhaps a local mail store is an optimal solution, but, for many of us, mail locked into a laptop is inaccessible much of the time.

That's the bad news. The good news is that the Notmuch developers have been working to improve interoperability with mail stored on an IMAP server. Notmuch still needs a local copy of the mail; the tool of choice to manage that copy appears to be Offlineimap. Recent versions of Notmuch are able to manipulate the "has been read" flags stored in Maildir filenames and to perform folder-based searches, despite the fact that "folders" are a foreign concept in the Notmuch world. The afew tool can be used to move messages between folders based on Notmuch tags; that means that local tagging can be reflected in IMAP folders on the server. These changes make it possible to use Notmuch in some settings, but still fall back on an IMAP-based client in others.

The initial task of copying the mail directory to the local machine where Notmuch is to be run (assuming it's not already there) will still be painful, of course. But, then, anybody who has sat through Thunderbird's indexing routine will already be used to that kind of suffering and may not even notice. Then it's a simple matter of running:

    notmuch setup

and answering some questions to create the initial Notmuch configuration, then:

    notmuch new

to read through and index all of the mail in the spool. The process can take a while for a very large mail spool, but it's surprisingly fast when one looks at how many messages are being processed.

The indexing of mail is done with the Xapian search engine. Xapian provides high-speed and flexible searching; it also performs "stemming," so that a search for "email" will also turn up "emails" and "emailed," for example. Stemming only works with English; extending it to other languages is not likely to be a simple task. Basic logical operators are supported; a search for, say:

    from:torvalds AND crap

turns up a long list of messages on a linux-kernel archive. Searches can be date-constrained; it is also possible to search for words or phrases that are near each other in the text.

The other fundamental Notmuch operation is tagging. The "notmuch new" command will apply some initial tags ("unread", for example); it can be configured to do more complex tagging in response to search queries as well. Searching itself can be limited to specific tags. As is the way of the modern world, Notmuch has pretty much done away with the concept of folders; rather than existing in a single folder, a message will have any of a number of tags.

Low-level access to the Notmuch search feature is via the "notmuch search" command; it outputs a list of matching messages (or threads) in a line-oriented format. Most users, however, will want to actually do things with the result of a search — reading the messages, say, or replying to them. That is where core Notmuch throws up its hands and declares that the problem is to be solved by some higher layer of software.

Several projects are working on producing a useful user interface for people who actually want to work with mail. There are a few alternatives for those who want to integrate Notmuch with the Mutt email client, including [Hello screen] the notmuch-mutt helper by Stefano Zacchiroli. Another terminal-based client is Alot. There is notmuch-vim for those who want to manage their mail through the vim editor, and notmuch-web to create a web interface.

The bulk of Notmuch users, though, would appear to be using the Emacs-based interface packaged with Notmuch itself. Starting the Emacs Notmuch mode is somewhat reminiscent of going to the main Google page; there is a search box and not a whole lot more. Once one picks a search ("unread" is a good starting place), the result is a dense screen showing the results in a one-line-per-thread format. Clicking on a line (or moving there and hitting "return") switches to a buffer with all messages in the thread, one after another. This view clearly works for many Notmuch users, but it's not entirely helpful for those of us who like to know what's in a thread before wandering into it.

Fortunately, the Notmuch 0.17 release added a new mode called notmuch-tree; it shows a tree-structured threaded view that is closer to what most other thread-oriented mail clients provide. In this [Tree screen] view, one can move through threads and messages in a fairly straightforward manner. There is a full range of functionality in either mode, including the ability to pipe a message to a command — a feature that is surprisingly hard to find in most graphical clients. And, of course, it's Emacs, so the interface is infinitely flexible.

If Emacs is running in the graphical mode, the experience is mostly like that of a graphical mail reader. The illusion falls apart a bit, though, when it comes to dealing with attachments. Emacs can deal with various types of attachments internally; it can do inline image display, for example. But Notmuch makes little use of those capabilities, relying instead on external helpers to deal with attachments. Having external image viewers and web browser windows pop up for attachments feels a bit less integrated than a contemporary graphical mail client, but it works well enough most of the time.

Mail composition is handed off entirely to the Emacs "Message" mode, which, for the most part, handles the job nicely. There is nothing like trying to edit a complex message in a graphical mail client's composition window to make one appreciate the virtues of having a real text editor available. That said, handling of attachments is, once again, a bit primitive for those who are used to a native, graphical, point-and-click interface, but it gets the job done. Naturally, Notmuch doesn't get into the business of actually sending mail at all; it assumes there is a sendmail command around somewhere that can send a message toward its destination.

So, one might ask, will Notmuch become your editor's new email client? The jury is still out on that one, but it might just happen. To a great extent, it comes down to whether a practical way for accessing email from multiple hosts, including some that use IMAP, can be found. Offlineimap seems like one potential option; there is also a way of using a remote Notmuch installation over SSH from an Emacs client, though the instructions warn that "some things probably won't work perfectly." In either case, part of the proof will be usability over a painful conference network connection. Even without a full-scale switchover, Notmuch can be useful for tasks like searching through an extensive linux-kernel archive, of course.

In general, it often seems like progress in the area of email clients came to a halt some years ago. The clients that actually are evolving are, for the most part, tied to cloud services; offloading one's email to a cloud provider may be a viable solution for some users, but many of us disliked that idea even before the extent of national surveillance efforts became widely known. So it is good to see communities like Notmuch trying to get back to the basics of what makes an email client work well, and it is good to see that Notmuch, in particular, appears to be picking up speed. Notmuch remains a project worth watching.


(Log in to post comments)

A Notmuch mail update

Posted Feb 20, 2014 4:41 UTC (Thu) by nteon (subscriber, #53899) [Link]

The notmuch-tree screenshot (and specifically the RFC in the middle) is simply amazing.

Org-mode integration

Posted Feb 20, 2014 5:09 UTC (Thu) by tnoo (subscriber, #20427) [Link]

Besides being a very nice Email interface that JUST WORKS, the killer feature for me is its integration with org-mode. While reading email I can create TODO items or other tasks that appear in org-mode's task list or project buffers. This is invaluable creating context in a heavily email-based work flow.

Org-mode integration

Posted Feb 20, 2014 5:59 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I'm mainly a mutt user who uses tmux to get such functionality for the most part (split the window, use taskwarrior or Vim). I use notmuch mainly when searching for long lost emails. The main barrier for heavier use is syncing notmuch's metadata between my machines. Do you have any suggestions?

A Notmuch mail update

Posted Feb 20, 2014 9:21 UTC (Thu) by skx (subscriber, #14652) [Link]

Although this won't suit you, if you like using IMAP, and find the need for "local mail" a pain, I have to say that I've spent the past few months working on another console based mail client.

Like many people I started off using mutt but soon found the configuration was more complex than I wanted, but at the same time too limiting.

I wanted something "like mutt", but with a real scripting language for configuration.

Ultimately that lead to lumail, a console client operating solely on local Maildir-hierarchies, and fully scripted/scriptable with lua.

Recently I've been pondering the idea of swapping out the maildir-backend to a intermediary store, such as notmutt's backend, but I've not yet started down that path.

A Notmuch mail update

Posted Feb 20, 2014 14:41 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

There's a website I used to bootstrap my mutt configuration, but the rest wasn't too bad (I was also in college, so free time was readily available, FWIW). What did you want out of it (I've never felt the need for a language for the configuration, but, but maybe I'm missing something)?

A Notmuch mail update

Posted Feb 20, 2014 14:50 UTC (Thu) by skx (subscriber, #14652) [Link]

I wanted to have a configuration tree that was nicely broken down into "global" and "per-host".

I did manage to get something like that by using shell to evaluate expressions like this:

#
# load ~/.mutt-ssh or ~/.mutt-foo depending on 
# the hostname of the current machine
#
# If there is no per-host file then load ~/.mutt-global instead.
#
# It is assumed that any per-host files will end by loading the global
# configuration file such that we get both "global" and "per-host" things
# loaded.
#
source ~/.mutt-`test -e ~/.mutt-$(hostname -s) && echo $(hostname -s) || echo global`

Similarly I wanted to handle conditional configuration easily when using mutt or mutt-patched. But above all I wanted to avoid hacks where I'd rebind macros to re-source different configuration files to do things.

A Notmuch mail update

Posted Feb 20, 2014 14:56 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Ah, that's handled by my configuration management scripts, not tools themselves. For mutt, I have a sharded config (e.g., 70-bindings.muttrc and 90-colors.muttrc) and the pieces can get symlinked based on the host. Currently, it is uniform, but adding it isn't out of the question.

A Notmuch mail update

Posted Feb 20, 2014 15:01 UTC (Thu) by skx (subscriber, #14652) [Link]

That is certainly one way of doing it.

I use configuration management to manage deployment of systems and applications, but the dotfiles that drive things all come from a git repository.

(So all my hosts will have either "dotfiles-public" or "dotfiles-private" checked out in $HOME.)

A Notmuch mail update

Posted Feb 20, 2014 15:03 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I use git as well, but it uses CMake to symlink enabled configs to the right place (ccmake is great for turning things on and off).

A Notmuch mail update

Posted Feb 20, 2014 15:04 UTC (Thu) by skx (subscriber, #14652) [Link]

PS. We don't need to get bogged down in the shortcomings, real or imagined, in mutt.

I just need to point at the Lumail Examples page which shows some of the things you can do if you have real scripting in your mail client.

Although this is my pet project I'm surprised there hasn't been more of a push for scripting in mail clients. (Excluding vbmacros in outlook, I guess the only obvious place where I see it is in emacs-land with things like gnus.)

A Notmuch mail update

Posted Feb 20, 2014 16:49 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

For the most part, all of my accounts are the same. I just set folder-based triggers to set things like the GPG key to use, which folder to save sent emails to, and From/In-Reply-To headers.

Of the features you list there, I think the one I'd actually want (that, AFAIK, mutt doesn't already have) is the foreach-folder style of command. Others like address book support is already in mutt, pattern matching for a command (tag mails by search then tag-apply'ing a command) covers mark_read_by_pattern() without the need for a new command for each pattern+command combo, and all-unread is covered with notmuch-mutt (I like to keep mail segregated by account, so all-unread isn't that useful to me). HTML and viewing attachments is handled decently enough for my tastes as well (w3m -dump or open-in-w3m for HTML and mutt's attachment list plus mailcap for non-inline-able attachments), but I can understand how that might not be enough for most people.

If your using Emacs then...

Posted Feb 20, 2014 9:34 UTC (Thu) by alex (subscriber, #1355) [Link]

...you may want to consider looking at mu (and it's Emacs front-end mu4e). I recently moved jobs to one where I needed to spend a lot more times in mailing lists and I compared Notmuch, mu and Gnus as alternatives. Obviously for my use-case I found mu4e the best of the 3. They all use some sort of offlineimap Maildir solution (in my case I went with isync/mbsync). For non-laptop/desktop access I just use the Google Mail apps on my Android devices as my corporate email is hosted there.

If you're using Emacs then...

Posted Feb 20, 2014 13:45 UTC (Thu) by hickinbottoms (subscriber, #14798) [Link]

I can second the recommendation for mu/mu4e. It's folder-based rather than tag-based so works well with multiple Maildirs.

I also use it with mbsync (which I find far quicker than offlineimap, but be sure to set mu4e-change-filenames-when-moving to keep mbsync happy), and when configured properly to use 'w3m' it can also make a good stab at showing HTML email within Emacs so you don't often have to launch a web browser on the message.

Using mbsync (or offlineimap) from multiple machines to regularly sync both ways back to a centrally-hosted IMAP server has worked well in my experience. This isn't much different to having something like Thunderbird download all messages automatically so it can build up an index except it's in Maildir format rather than something opaque inside the MUA, and mbsync is very quick to pick up only the changed messages even with my ~120,000 message archive.

Other advantages of offlineimap/mbsync to fetch mail are that you can easily automatically tunnel this securely over an SSH connection (perhaps you can also do this with Thunderbird, but I always ended up opening a manual SSH session with ports forwarded.)

If your using Emacs then...

Posted Feb 20, 2014 18:51 UTC (Thu) by jani (subscriber, #74547) [Link]

There's certainly plenty of overlap and similarities between notmuch and mu. Both use Xapian and gmime, both are mostly written in C, both work on maildir, both provide a set of cli tools, both have an emacs interface, etc.

I haven't had an in-depth look at mu; care to open up a bit in your comparison of mu and notmuch?

One of the biggest differences I know is best described by running 'git shortlog -s -n' in the projects' repositories. Mu remains a predominantly one man show, while notmuch has grown a wider developer community around it. (I'm not saying this would make notmuch somehow inherently better; indeed for the end-user mu might offer a more consistent experience because of this.)

reasons I went for mu4e

Posted Feb 20, 2014 22:21 UTC (Thu) by alex (subscriber, #1355) [Link]

I did do some basic analysis of the contributor base of notmuch and mu
as I also like to see that a project has a diverse developer
community. Although djcb does most of the work it's a good sign that a
large number of people can contribute code even if it's a small
proportion of the total.

The main reasons I went with mu4e where:
* Speed of indexing*
* Very quick navigation (bookmarks, shortcuts, narrow in a few keystokes)
* Nice threaded view of mail
* Useful documentation and clean elisp

* odd given they are both essentially Xapian databases.

reasons I went for mu4e

Posted Feb 21, 2014 5:12 UTC (Fri) by tnoo (subscriber, #20427) [Link]

After reading about mu4e I installed it and follwed advice on a standard installation. This is ceratinly a nice piece of code which I would chose if I were not using notmuch. But I did not find any functionality that mu4e provides which is missing in notmuch. All of your points are equally true for notmuch, except probably the last one (documentation).

docs

Posted Feb 21, 2014 9:07 UTC (Fri) by alex (subscriber, #1355) [Link]

But having good documentation is very important. It's true that being
elisp means you can always bend any aspect of the UI to your will but
if you have documentation describing where the customisation points
are you have a much better chance of working with the package.

Now my preference for the mu4e layout may well be personal but I did
prefer it over the default notmuch one. Anyway it's not hard to switch
between the two - they are both essentially offline Maildir set-ups
which is the big step to make.

reasons I went for mu4e

Posted Feb 25, 2014 11:38 UTC (Tue) by jani (subscriber, #74547) [Link]

> The main reasons I went with mu4e where:
> * Speed of indexing*

This is partially because mu does not do positional indexing. Per Xapian documentation, "This means that the database will be significantly smaller, but that phrase searching and NEAR won't be supported." You get some, you lose some.

> * Nice threaded view of mail

I played with mu4e a bit, and when searching for messages, I could not find a way to see the non-matching messages in a thread. Is that possible? Often one ends up wanting to see some context.

Notmuch now offers two views to search results: one thread per line search result view with "gmail like" view of a single thread, and the new "mutt like" one message per line threaded result view with messages displayed in another window. (Disclaimer, I contribute to notmuch, and this is a shameless plug. ;)

reasons I went for mu4e

Posted Feb 25, 2014 15:33 UTC (Tue) by hirnbrot (subscriber, #89469) [Link]

> I could not find a way to see the non-matching messages in a thread. Is that possible?

(setq mu4e-headers-include-related t)

may do what you want.

A Notmuch mail update

Posted Feb 20, 2014 11:45 UTC (Thu) by paulj (subscriber, #341) [Link]

I use Pine^WAlpine. It's still a great MUA. It's both user-friendly, with prompts for applicable key commands at the bottom of every screen, and powerful with excellent searching. The searching facilities allow you to apply query to query, narrowing down or broadening the selected emails as you go, according to various criteria. You can 'tag' emails too with labels, and use those for searching. Its IMAP support is very good too.

It can do a text render of HTML email, though of course you may sometimes still need to have Alpine hand off an email to your browser. I find I need this only very very rarely though. Also, that my MUA *doesn't* load images, like little bugs, or interpret JavaScript, is something I actually consider a feature.

Anyway... ;)

A Notmuch mail update

Posted Feb 20, 2014 12:27 UTC (Thu) by paulj (subscriber, #341) [Link]

Oh, and Alpine is also reasonably user-friendly to configure - again, through prompted configuration screens, with in-built help.

A Notmuch mail update

Posted Feb 20, 2014 17:55 UTC (Thu) by jani (subscriber, #74547) [Link]

I used (al)pine for years before switching to notmuch. I hoped the license change with the Alpine release would have created a real community around it, but as far as I could tell, nothing of the sort ever happened. How is Alpine doing these days development wise?

I had a look at the Alpine source ages ago with hopes I could scratch some of the itches I had, but frankly it scared me away...

Part of the reason for picking notmuch was the community around it, and the IMO high standard of the code base.

A Notmuch mail update

Posted Feb 20, 2014 20:12 UTC (Thu) by paulj (subscriber, #341) [Link]

It's doing fine. With the Alpine move, I think some work has gone in that was in external patches, e.g. the UTF-8 support seems solid now. Generally though Alpine is very mature software, and there's not really much that needs to doing it, really. So I havn't really had to look into how the development community is doing. :)

A Notmuch mail update

Posted Feb 22, 2014 0:12 UTC (Sat) by domo (subscriber, #14031) [Link]

Alpine, Mutt and whatnot, are probably very good mail programs, but
the biggest showstopper for me would be lack of Emacs keybindings ;D.

I switched from elm to VM on emacs early 90's, to Gnus 2005 and to
Notmuch 2011, 2nd. best thing in notmuch for me is that I can tune
anything to my liking :D...

A Notmuch mail update

Posted Feb 22, 2014 23:17 UTC (Sat) by paulj (subscriber, #341) [Link]

You can use whichever editor you want with Alpine. Though its default supports a few basic movement ones.

A Notmuch mail update

Posted Feb 20, 2014 12:07 UTC (Thu) by jani (subscriber, #74547) [Link]

Thanks for a detailed and fair review!

FWIW, I use the remote notmuch setup on a regular basis on my laptop (with the notmuch installation on a desktop machine), and the rare hickups are related to network connectivity. The main downside is the need to have the desktop up and running to access mail.

Developers and email clients

Posted Feb 20, 2014 16:55 UTC (Thu) by smoogen (subscriber, #97) [Link]

Corbet: It is continually surprising — and frustrating — to see how hard it seems to be for our community to do a good job with one of the tools it relies upon most heavily.

---

I wonder how much of this is that developers are highly idiosyncratic and tend to do things completely different from each other. I know at least 20 different developers who use emacs GNUS but each has it set up completely differently and none of them like any others setup. The same with mutt users or various other clients. It is like watching tom cats thrown in a box at times.

A Notmuch mail update

Posted Feb 20, 2014 17:30 UTC (Thu) by ssmith32 (subscriber, #72404) [Link]

>Stemming only works with English; extending it to other languages is not likely to be a simple task.

Well, at least according to the Xapian documentation, that is not true:

http://getting-started-with-xapian.readthedocs.org/en/lat...

"The rules applied by a stemmer are dependent on the language of the text; Xapian includes stemmers for more than a dozen languages (and for some languages there is a choice of stemmers)."

( Well, the part about not being a simple task is likely true, though :) )

A Notmuch mail update

Posted Feb 20, 2014 19:49 UTC (Thu) by cworth (guest, #27653) [Link]

>> Stemming only works with English; extending it to other languages
>> is not likely to be a simple task.
>
> Well, at least according to the Xapian documentation, that is not true:

Xapian does have good support for stemming in multiple languages, yes.

I don't know if notmuch has a configuration option to select the
primary language used for indexing email. But if not, that would be
easy to add.

It would be a bit less simple to have notmuch support multiple
languages simultaneously. At least one non-trivial task would be the
automatic detection of the language of each email. There do appear to
be some free-software libraries for this task, but I've never
evaluated any of them for suitability.

-Carl

PS. Jonathan, thanks for the second review of notmuch. I'm delighted
that you're seeing good progress in the project. It is extremely
rewarding to me personally to see that the notmuch community remains
vibrant after I have largely stepped away from it, (as far as active
development---I'm still entirely dependent on notmuch as a user).

A Notmuch mail update

Posted Feb 21, 2014 9:09 UTC (Fri) by jezuch (subscriber, #52988) [Link]

Soooo.... Is anyone working on a notmuch backend for Akonadi? ;)

A Notmuch mail update

Posted Feb 22, 2014 10:05 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]

To replace what, mysql, as cache? Note that the upcoming Akonadi/Baloo combination in KDE Applications 4.13 (heading for June release) will use Xapian for search ;-)

A Notmuch mail update

Posted Feb 24, 2014 8:24 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> To replace what, mysql, as cache?

Yeah. Why not?

> Note that the upcoming Akonadi/Baloo combination in KDE Applications 4.13 (heading for June release) will use Xapian for search ;-)

Ah. So did the pushback against Nepomuk "force" them to choose some other search implementation? (I tried to turn on Nepomuk just for the mail indexer but it never managed to crunch through my ~15 years of archived mail. So I have to live without mail search.)

A Notmuch mail update

Posted Feb 21, 2014 16:19 UTC (Fri) by Shugyousha (subscriber, #93672) [Link]

I use notmuch with mutt but rarely feel the need to run it.

Just out of curiosity: is anyone still using nmh (http://www.nongnu.org/nmh/) or maybe even its fork mmh (http://marmaro.de/prog/mmh/)?

A Notmuch mail update

Posted Feb 21, 2014 21:38 UTC (Fri) by treed (guest, #11432) [Link]

I tried notmuch using offlineimap to sync the mail and I found offlineimap to be infuriatingly unreliable. I wouldn't get any mail all day only to realize that mail had been piling up on the server and offlineimap had wedged somehow. I don't recall the ways in which it had wedged but I tried getting some help from the devs and sending bug reports etc but never got anywhere. I love the idea of notmuch and using tags and making my mail searchable. But I hate unreliable email. So I'm still using mutt and its reliable IMAP support for the time being.

A Notmuch mail update

Posted Feb 21, 2014 22:50 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

What version of offlineimap? It recently (in the last year or two?) had an overhaul which made it much more reliable for me. I still use mutt, but notmuch is there too for global searches.

A Notmuch mail update

Posted Feb 22, 2014 13:32 UTC (Sat) by gregoa (subscriber, #51778) [Link]

I replaced offlineimap with http://syncmaildir.sourceforge.net/ some 2 years ago and still am quite happy about the change.

A Notmuch mail update

Posted Feb 22, 2014 23:56 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Okay, but how do you talk to IMAP servers then? It looks like smd just talks over SSH...which I won't get for, say, work.

A Notmuch mail update

Posted Feb 23, 2014 1:12 UTC (Sun) by gregoa (subscriber, #51778) [Link]

Correct, smd needs ssh access, so won't help for imap-only servers.
(I should have mentioned this before, sorry.)

A Notmuch mail update

Posted Feb 23, 2014 2:06 UTC (Sun) by lsl (subscriber, #86508) [Link]

I wonder why nobody mentioned Karel Zak's mutt-kz branch of Mutt yet. It's basically Mutt with nice integration of Notmuch. I just switched to it a week or so ago but from what I've seen it's pretty awesome. Plus it has the feature that existing Mutt users can make use of Notmuch's functionality in an incremental way, as all of good old Mutt is still there.

Mutt users should definitely give it a try:
https://kzak.redcrew.org/doku.php?id=mutt:start

A Notmuch mail update

Posted Feb 27, 2014 1:35 UTC (Thu) by CycoJ (guest, #70454) [Link]

I'm similar to Jonathan in that I haven't switched to notmuch mainly because of having to access mail from several locations. For a while I was hoping that heliotrope (initiated by the creator of sup) would gain some traction, but development has essentially stopped.
One of the things that I find particularly annoying is that IMAP actually supports tags (via IMAP keywords), but none of the synchronization tools support it. Furthermore, there's also good server based search support through sieve, but again hardly any support in clients.
What I'd really like is a tagging email client with mutt (vim) bindings and server based search with possible local caching. Somehow the only email client for remote email based on tags seems to be the gmail webinterface. I find it utterly surprising that no one has reproduced a similar interface for a local client.
Currently I'm using thunderbird with the muttator plugin, which gets me half-way there, but the tag support in thunderbird is quite useless and the external editor support does not work well either in my experience.

A Notmuch mail update

Posted Jun 5, 2015 15:20 UTC (Fri) by dr@jones.dk (subscriber, #7907) [Link]

Dovecot imap server includes dsync which does syncronization including the tags.

A Notmuch mail update

Posted Mar 16, 2014 21:21 UTC (Sun) by rakoo (guest, #96001) [Link]

I find it surprising that no one has mentioned sup, the original ncurses search-based MUA from which notmuch departed, so here you go. Sup features a lot of what you would be searching for in notmuch-and-its-frontends and mu/mu4e. The notmuch people have decided to start from scratch because of speed, which I find more than enough even though sup is written in ruby. For a moment I tried hacking on heliotrope/turnsole, but it was still a prototype that wasn't working completely, so I decided to divert my efforts toward sup because it's working and is used by some people now. It is quite configurable and you can even go further with hooks to manage custom actions. You can have multiple backends (called sources), the standard ones being mbox and maildir. There is some work to use a gmail source that speaks direct IMAP with gmail, and another one that is basically a directory of maildirs (use case: offlineimap to a folder, use that folder as a source, every label management is reflected in the folders just like gmail does). Feel free to have a go at it !


Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds