Re: Implementation of virtual folders in mutt
My preference for virtual folders thus far has been to use the "limit"
suggestion.
That is -- I store a bunch of mail in one mailbox (the INBOX). I then flag
some
messages using "F".
To view the virtual mailbox, I then have a macro setup as:
macro index <ESC>4 '<limit>~F<enter>' "View flagged messages"
Thus, when I type alt-4, it shows me only the flagged messages. I also map
alt-0
to be ~a for all messages. alt-1 to alt-3 are similar maps for messages
received in the last 3 days, and messages with and without a label applied in
procmail through X-Label.
Since it's not a folder for Mutt, it doesn't get folder hooks or anything like
that, but otherwise it works fine, and requires no patching.
Would this kind of setup work for you?
FWIW -- I get the idea from another poster talking about virtual mutt folders.
-Chip
On Wed, Aug 09, 2006 at 01:22:14PM -0400, Chris wrote:
> 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?
--
====
Chip Killian
http://chip.kcubes.com