On 10/06/04 17.02, M. Fioretti wrote:
> On Thu, Jun 10, 2004 15:53:54 PM +0200, Mads Laursen
> (dossen+mutt@xxxxxxxxxxx) wrote:
[snip]
> > Then feed the messages to a script, that extracts msgids (and possibly
> > other identifying headers) and appends them to a file.
>
> I want to act (= tag & pipe to script) only on the beginning of the
> thread, and then forget about it. If I pass to procmail the msgid of
> the first message, how will it act on the replies of replies of
> replies.... This is why I was thinking to let the whole thread pile up
> in mailboxes, and have mutt not show it based on how the parent
> message is recognized.
I agree that a solution using scoring, limiting and other mutt tricks
would be nice and simple (relatively), but when I said messages, I
meant it. If you just feed the entire thread to your script (I know
mutt can tag a whole thread in one go) and it records all the msgids,
then procmail can easily check against this list, and add any msgids
that are caught. And wrapped suitably in a few scripts (and some
procmail compatible locking), this approach could be extended to allow
kill-file based on anything procmail can match (say any part of a
thread that follows up to someone from aol.com (generic example)),
unkill-file of specific individuals (say you have a friend whos
answers you always want, even if they are in a killed thread) or
subthreads, etc. But I'd probably look for something that's close to
right and go from there. Maybe swing by the procmail list, and google
a bit?
> Of course, I would still be invited by mutt to go in mailboxes with
> new, even if uninteresting email. Or not? Any way to avoid that,
> without:
>
> > /dev/null the matching mails, you can file them to a seperate mailbox,
I think this bit from my procmailrc:
:0 fw
* !^Status:
| $FORMAIL -I "Status: RO"
does the trick for me, but this is for an IMAP server, with mbox
storage. I don't know if procmail can deliver as read on maildir? On
mbox you could probably use my trick, followed with something like:
:0: somelockfile.lock
{
DUMMY=`touch --reference=<your mbox file> /tmp/<some unique file>`
:0 c
<your mbox file>
DUMMY=`touch --reference=/tmp/<some unique file> <your mbox file>`
DUMMY=`rm -f /tmp/<some unique file>`
:0
/dev/null
}
I think that should deliver the mail without changing the timestamps
on the mbox file (unless mutt happens to check just between the two
calls to touch).
Anyway, that's just off the top of my head.
HTH, HAND.
/dossen
--
Common sense is the collection of prejudices acquired by age eighteen.
-- Albert Einstein
Attachment:
pgpCGZOeCAZoX.pgp
Description: PGP signature