[linux-elitists] New list, keysignings
Tue Apr 2 15:03:03 PST 2002
* Nick Moffitt (firstname.lastname@example.org) [020402 16:42]:
> begin Rick Bradley quotation:
> > The only downside is maintaining two sets of filtering rules
> > (procmail and save-hooks) but that's constant time per stream so I
> > decided I don't mind.
> NO, it's O(N) on the mutt side. My procmail rules are
> constant time, since subscribing to new lists doesn't require me to
> enter in new rules. Your mutt hooks require the addition of new hooks
> each time you subscribe to a new list.
Now we're quibbling over computation models. I agree that O(1) per
stream is O(n) per person; and your scheme is O(1) per person -- at
least for rule maintenance.
A few years ago I went to something like your system, but found that I
was being overwhelmed by the amount of mail I was receiving. I was
trying to read large portions of a folder when something important came
in, or letting a large share of my mail languish indefinitely, or simply
missing important bits until it was too late to act on them. The worst
thing was going away for a week and coming back to thousands of messages
and having to sift through the various folders to straighten things out.
Eventually I came up with a system to prioritize correspondence
(particularly lists) in addition to categorizing the prioritized mail by
subject matter. A number of lists just go to their destination folders,
but many of them are sent elsewhere first, and if they're important
enough I see them immediately, otherwise I can check them every hour or
so, otherwise I can check them at the end of the day, otherwise whenever
I feel like it. If there are, for example, legal matters brewing that I
want to follow then I can get to the important messages instantly,
similarly for various social groups, etc.
The save-hooks make sure that priority messages ultimately end up in the
right place without me having to remember where to file them. Could I
trim down my procmailrc by doing some heavy factoring? Yes, but that
would increase the complexity of a single rule editing operation which
is currently trivial, and make rules more fragile.
I see the beauty of your solution, it just simply doesn't work for me
since in my complexity model rule maintenance is cheap (especially
amortized over mail reading), but manual prioritizing and sifting is
http://www.roundeye.net MUPRN: 814 (82 F)
| see how they work (you
random email haiku | might have already) it might
| speed things up later.
More information about the linux-elitists