* Rob Reid <[EMAIL PROTECTED]> [2002-03-24 20:20]: > At 8:25 PM EST on March 23 Sven Guckes sent off: > > * Rob Reid <[EMAIL PROTECTED]> [2002-03-22 01:18]: > Hey, you changed your attribution string! ;-)
(sssh! dont tell anyone - ok?) > > > Is there a way to pass the location of the > > > current folder to the shell? > > no. unless you have set MAIL before starting > > mutt - then it'll be accessible via $MAIL. > Yeah, but that means one mutt per folder. > Thanks but no thanks. ;-) there could be a lot more done if mutt exported some infos about its current state via shell variables - but then there's LOT of things which could be important to someone. saving the complete current state to a tempfile probably is the best solution here - but could also become a problem in many ways. (swapping out the pgp passphrase? of course NOT!) > > yep, MIDs are probably best for checking. > I already have MID killfiles, but subjects have > some advantages: 1. Sometimes people > reply in a thread but change the subject. > I'd like to know when that happens. hmm.. then you'd have to save the combinations of MIDs and SUBJECTs. or does this need yet another pattern? (there's one for "duplicates" now - and I really like it. you know, "delete-pattern" by "~=". hehe) > 2. More importantly, threads have a way of > recurring. i.e. on Jan. 2, somebody could > write "Problem sending PGP to Outlook", and a > thread will start and finish within a week. .. > sooner or later someone else will start another one > on the same topic, but the MIDs will be different. ok - but there's nothing you can do against that, right? how will you detect such things? "adaptive scoring"? > 3. If the killfile ever gets too big, the subjects > make more sense than the MIDs when deciding what > to throw out. It also helps to trim them down to > only the important words (PGP Out look) to catch > recurring threads with slightly different titles. ok, but that's a *filter* problem - not a mutt problem, right? Sven [rearranging his procmail setup]
