Re: Hide (future) uninteresting messages
On 10:37 11 Jun 2004, Mads Laursen <dossen+mutt@xxxxxxxxxxx> wrote:
| 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.
So you need to tag the thread, pipe each message to the killer, delete
the messages. And then have the killer's table be used in procmail when
delivering new mail to track the killed threads.
| 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.
Indeed. I've been thinking about this, on and off, for a year or so now.
And of course done nothing. But this afternoon I did a little hacking.
Herewith I present two scripts:
http://www.cskk.ezoshosting.com/cs/css/bin/kill-thread
http://www.cskk.ezoshosting.com/cs/css/bin/track-thread
which need this one too:
http://www.cskk.ezoshosting.com/cs/css/bin/mhdrs
With these I'm now using this procmail recipe:
:0 Whc
| track-thread $HOME/var/killfile
:0 a:
killed/.
killfile is a flat text file with message-ids in it, one per line.
It's used much as you anticipate; children of killed messages get
dropped into the "killed" folder and have their own message-ids added
to the killfile to catch the grandchildren and so on. It seems to work.
(With one caveat: child messages must not preceed their parent in arrival,
which works for email on the whole and not so well for news).
You may notice it doesn't lock. The code is so simple that it doesn't
need to. Adding a message-id is a simple "echo id >>killfile" which will
never overlap another echo on a UNIX system:-) Even over NFS I suspect,
given the nature of >>, which uses O_APPEND.
My desire is to be able to mark a _branch_ of a thread as boring.
So far I have only this very crude macro:
macro index ,k "<pipe-message>kill-thread
$HOME/var/killfile<enter><copy-message>+killed<enter><delete-message>" "kill
this message's direct descendants"
macro pager ,k "<pipe-message>kill-thread
$HOME/var/killfile<enter><copy-message>+killed<enter><delete-message>" "kill
this message's direct descendants"
which feeds a single message to the killfile.
I suspect the approach I will need to use is a tedious "tag this message
and all the children so far, then tag-pipe-message them all to the killer".
Of course the killfile will grow slowly (or quickly if you don't suffer
fools gladly), but the top messages are the old ones. Just yank it
if thinks seem slow. However I suspect it'll run quite well for quite
a while without any meddling at all.
As Mads remarks, this could readily extend to auto killing threads at exactly
the point your local troll enters it, if you know his/her email address:-)
Thus leaving the unpolluted branches "live".
Cheers,
--
Cameron Simpson <cs@xxxxxxxxxx> DoD#743
http://www.cskk.ezoshosting.com/cs/
Gauls! We have nothing to fear; except perhaps that the sky may fall
on our heads tomorrow. But as we all know, tomorrow never comes!!
- Adventures of Asterix