<<< Date Index >>>     <<< Thread Index >>>

Implementation of virtual folders in mutt



Hello, all.  I'm trying to implement a virtual folder in my mutt setup,
in the same idea as Outlook's 'For Follow-Up' mailbox or gmail's Star --
messages that need to be dealt with in some way.  I want it to be a
virtual folder so I don't have to go looking for the messages nor change
my current mail organization scheme.

My mail is stored in Maildirs in ~/Maildir.  I wrote a quick shell
script to look for flagged and new messages and symlink them to a new
mailbox.  Despite my 300MB of email, this script runs in only a second
or two (probably because it only needs to scan filenames).

The problem is that mutt modifies the filename of the symlink (rather
than the original message) if I respond to it, unflag it, etc.  

If I switched to editing something in the body of the email (such as an
X-Label header) to track flagging and such, that would bypass the
symlink problem, but would be *much* slower.

It seems to me I can either write a script to parse the symlinks and
rename the original messages to match (but that requires running it on
leaving the mailbox, which mutt doesn't easily do), or patch mutt so
that will update both the symlink filename and the message filename
(more effective but more work).  [I have nmzmail already (rather than
mairix), but updating the database each time is not very efficient.]

I am leaning towards patching mutt, both because the end result is the
most transparent to the end user, and because if muttrc options are
added so that it is applied only in selected mailboxes, one can easily
implement gmail-style tagging with procmail, nmzmail/mairix, and X-Label
headers.

Before I start poking around in the mutt source, does anyone have a
suggestion on a better way to implement this?  Or any suggestions on the
easiest way to patch the source?

[Other approaches I considered:

- a script to update the message filename as mutt updates the filename;
doesn't work well because mutt seems to hold off updating the filename
until the mailbox as a whole is updated, and can get out of sync with
canceled actions (such as Reply)

- a script to update the message filename based on a header (e.g. one
script sets "X-Status: replied", another will update the filename
based on that header then remove the header); this has the same
downsides as the previous approach

- using X-Label (or something else in the headers) to flag, but grep is
slow, and I haven't seen how to get namazu/nmzmail to update just one
message nor mutt to display the filename of the current message (my
scripts currently grep the output of <pipe-message> for the message-ID
then grep the files in the directory for a match)

- setting a hotkey to jump to the right folder & message (probably by
using ~i $MESSAGE_ID), but I don't see any inbuilt variable to use for
that nor how to get mutt to use the result of an external command in an
internal action (otherwise I would just
"<change-folder>`extract_folder`<find-message>~i `extract_message-id`"
or similar)

- my favourite idea, currently rejected because of the size of the
project, is to have a program maintain a database (such as SQL) of
message data (filename, sender, recipient(s) message-id, date) and tags,
and be capable of providing a virtual filesystem with maildir symlinks
to the actual messages; would have to be called in .procmailrc or
similar to tag everything and at every status change, but could provide
real gmail-style tagging, be very responsive, and potentially useful for
more than just email 
]


-- 
Chris Witham <christopher.witham@xxxxxxxxx>
Computer Engineer and Geek
Fan of video games, anime, and the outdoors

if there's an exception to every rule, 
is there an exception to that rule?