Dear lazyweb: I love mutt, my
faithful mail client for almost a decade now, but I think I've
reached its limits. Not that
mutt isn't doing fine,
it's more my way of organising mail that's no longer working for
me. To give a short overview: I receive all mail in a
single account and filter messages to folders in a hierarchy. My
filter set spans several thousand lines and has been growing for
seven years now, the last "refactoring" was in 1999.
When browsing mail, I either delete messages (for list mails
mostly) or save them to the
read folder when I am done
The hierarchy is mostly arranged by field of endeavour, and then
subdivided into specific topics. For instance, I have
I currently face two major problems with this approach:
Folders just don't cut it anymore. For instance: with my job, research, and hobby all somewhat connected to Debian, most messages I receive don't belong into one folder any more than they should be in another. What I want is effectively what gmail and several of the GUI clients do: any given message can have a number of tags, and virtual folders act as filters to display only messages with a certain tag.
Having a single
readfolder for all worked for a while, but it's long been a major pain. What I really want is for sent and received mail to sit right next to each other in all cases, ideally based on tags as well.
mutt's X-Label patch
mutt package includes it), which seems to
go in the right direction, but it's not exactly what I want (yet).
For my purpose, it adds a selector
~y to use in
searches and when limiting the display of a mailbox. Thus, I could
implement virtual folders by saving all mail to a single folder
(thanks to the
header_cache patch), then executing
l~ydebian to see all messages tagged
The problem with this approach is that it uses a functionality
that I already use extensively: limiting. I like the thought of
being able to use tags as filter criteria, but I don't want to
depend on them. For instance, if looking at all messages with the
debian tag, and then filtering those with
mdadm in the subject, I currently have to hit
l<space>~s mdadm (taking care to preserve the
label limit), and I cannot use the
In the end, what I'd want is to be able to use the folder syntax
for tags. Specifically, I think it would be cool to have folders as
they are currently, but if you try to change to a folder that does
not exist, or prefix the folder with
=vfolder/debian/mdadm), it would instead display the
main folder with the different path components used as label
filters. A syntax for logical
OR would also be nice.
All this should happen without affecting the limit functionality of
I don't think this is currently possible, but before I start to
pretend to plan my intent of eventually thinking about what it
would take to have a go at coding a patch, I'd welcome your feedback. I can't
imagine that I am the only one wanting
NP: Log / Every Time a Bell Rings, an Angel Gets His Wings
Update: people have pointed me to Gnus and Mairix. I'll have to check out Gnus, but I wonder whether it can be used the way I do mail: currently, I use offlineimap (my favourite software award 2004-2006) to synchronise my Maildirs across a total of eight machines, so that it does not matter where I read my mail -- it's totally synchronised. I'll give Gnus a whirl soon though. Manoj already showed it (off) to me, and several other Debian developers seem to swear by it, so it can't be all wrong.
With respect to Mairix, I know that tool; it basically populates
folders with symlinks according to search criteria. One could say
it instantiates virtual folders. The problem I have not been able
to solve yet is quite simply that operations such as moving
messages to other folders then operates on the symlink, which is
not what I want, for obvious reasons. Even just using
mutt to edit them results in a copy made, so the
symlink association is lost. I'd be happy to be shown how to use
the tool to make it do what I want.
NP: Led Zeppelin / Led Zeppelin I
Update: Steve picked up the issue of mutt mail tagging and came up with an interesting hardlink-based solution. He replicates filenames, so that status like 'read' or 'flagged' propagate to his tag directories, but that's one way, meaning that changes to the status via the tag folder will be lost. Even though it's not what I am looking for, it's closer than anything else.