Re: Deleting portions of large mail folders

2002-07-06 Thread Dr. Sharukh K. R. Pavri.

On Fri, 05 Jul 2002, Rob 'Feztaa' Park wrote:

 Alas! Wayne Chapeskie spake thus:
snip
 
 You see, I don't have a .muttrc. I have a perl script that generates my
 .muttrc for me, every time mutt is run. It automatically detects all my
 mboxes, and writes mbox hooks for them ;)

mind sharing it ? you can send it to me offlist if you want.

regards,

Sharukh.
-- 
Dr. Sharukh K. R. Pavri Homeopath and Linux Enthusiast.
Mumbai, India.  http://www.pavri.net/



msg29414/pgp0.pgp
Description: PGP signature


Re: Deleting portions of large mail folders

2002-07-06 Thread Rob 'Feztaa' Park

Alas! Dr. Sharukh K. R. Pavri. spake thus:
 On Fri, 05 Jul 2002, Rob 'Feztaa' Park wrote:
 
  Alas! Wayne Chapeskie spake thus:
 snip
  
  You see, I don't have a .muttrc. I have a perl script that generates my
  .muttrc for me, every time mutt is run. It automatically detects all my
  mboxes, and writes mbox hooks for them ;)
 
 mind sharing it ? you can send it to me offlist if you want.

I'd rather not. It's highly specific to my system and my tastes. It
would be totally worthless to you in anything but concept.

You're probably better off making your own. You don't have to use perl ;)

-- 
Rob 'Feztaa' Park
http://members.shaw.ca/feztaa/
--
When a woman becomes a scholar, there is usually something wrong
with her sexual organs.
-- Friedrich Nietzsche



msg29417/pgp0.pgp
Description: PGP signature


Re: Deleting portions of large mail folders

2002-07-05 Thread Rob 'Feztaa' Park


--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Alas! Wayne Chapeskie spake thus:
 On Tue, Jul 02, 2002 at 01:20:01PM -0600, Rob 'Feztaa' Park wrote:
  * because of the wonderful mbox-hooks, every time I leave a folder, all
  the mails I read are moved into the appropriate archive folder.
=20
 Do you have an example of how you set up the mbox-hooks automatically?
 I'm assuming a bunch of lines of the form
 mutt-hook =3Dmutt-dev =3Darchives/2002-07-mutt-dev
 but I'm not quite sure how to get get the year and date in there
 automatically, since I doubt you update your .muttrc every month.

You could try this:

mbox-hook =3Dinbox =3Darchives/`date +%Y-%m`-inbox

But it gets better! Lets say I unsubscribe from one list and subscribe
to another... I don't even have to make a new mbox-hook, or delete the
old one! ;)

You see, I don't have a .muttrc. I have a perl script that generates my
=2Emuttrc for me, every time mutt is run. It automatically detects all my
mboxes, and writes mbox hooks for them ;)

--=20
Rob 'Feztaa' Park
http://members.shaw.ca/feztaa/
--
Bureau Termination, Law of:
When a government bureau is scheduled to be phased out,
the number of employees in that bureau will double within
12 months after the decision is made.

--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9JeyxPTh2iSBKeccRAoDcAJ9EwGlZajocjJB9KRrAN0/BRmvTlQCfeQBb
kdG198Doc6b4HOO031Mv4ww=
=ZMbu
-END PGP SIGNATURE-

--FCuugMFkClbJLl1L--



Deleting portions of large mail folders

2002-07-02 Thread Wayne Chapeskie

This is a both a suggestion for a message pattern matching facility
which currently isn't implemented, and a usage question about
how to use the existing capabilities of mutt more efficiently.

I subscribe to many (probably too many) mailing lists.  Most get
automatically sorted by procmail to their own mail files.  Some of
these folders quietly accumulate hundreds, thousands, and in one case
tens of thousands of messages over the course of months or years.
Every so often I take a look at these and try to keep some of the
messages and get rid of the rest.

Most of the messages in such mail folders are going to be deleted
unread.  I have found that while targeted subject or author searches
are useful, my usual tool for identifying what I want to read is the
Mark I eyeball--a quick scan over an index screen with a threaded
subject listing, with a few quick previews is usually enough to
identify what I want to keep.  Manually deleting each unwanted message
or thread is fine when deleting on the order of tens or dozens of
unwanted messages/threads.  However, this gets tedious when I want to
delete hundreds of messages/threads.  In this case, the ~U pattern
is my friend, and it isn't too much of a problem to go through a few
screenfuls of messages, pick out the ones to save, and delete the
other several hundred unread messages.

Where my current methods break down is dealing with mail files with
thousands of unread messages.  I have found that it isn't practical
to do even a cursory scan in one sitting of all of the message index
displays before discarding all of the unread messages (~U).  In that
case I either give up and get of all the old messages, perhaps losing
something that I might want to read, or just continue to let messages
accumulate without trimming significantly.  While mutt easily handles
mail files with tens of thousands of messages, and tens or hundreds
of megabytes (given sufficient tmp file space), I don't really like
letting things get that big without cleaning it out.

I can scan a portion of the unread messages in one session, so what I
would like to be able to is to match, in some fashion, the messages
that I have scanned.  One possibility would be a pattern, say ~I,
which would match all messages currently displayed in the Mutt
index display.  Then I could bind a key sequence to something like
delete-pattern ~I ~U and scan and delete messages a screenful at a
time.

My ~I pattern doesn't seem to be currently implemented in Mutt, so
I'll throw it out as a suggestion.  

How do the rest of you handle cleaning out really big mail folders?

Thanks,

-- 
Wayne Chapeskie
GnuPG/PGP KeyID: 0xB9D2D272



Re: Deleting portions of large mail folders

2002-07-02 Thread Andre Berger


--bCsyhTFzCvuiizWE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Wayne Chapeskie [EMAIL PROTECTED], 2002-07-02 08:16 -0400:
[snip]
 How do the rest of you handle cleaning out really big mail folders?

1.  collpased threads

#collapse threads
folder-hook . push \eV
set collapse_unread=3Dyes
set uncollapse_jump=3Dyes

2.  delete duplicates

#Delete duplicates
folder-hook . push D~=3Denter

3.  scoring to delete old Mails either not related to myself directly
or flagged as important (which is the criterium to keep mails):

# index_format is of course optional
set index_format=3D%4C %2M%Z%2N %[%y%m%d] %-17.17F (%3l) %s
set score_threshold_delete=3D0
set score_threshold_flag=3D30
set score_threshold_read=3D15
unscore *
score '~A' 20
score '~=3D' -
score '~P|~p|~Q' 20
# delete unflagged and non-me-related mails oder than 14 days
folder-hook . 'score ~=3D|(!(~p|~P|~Q|~F)~d14d) -'
# Flagged as !
color index cyan default '~F'

4.  archiving the surviving mails (using Esc S) to a folder save.
plus foldername:

#Delete old; archive
macro   index   \eS   1\ncollapse-alluntag-pattern~A\ntag-pattern=
(~P|~p|~Q|~F)~r3w\n;s\n Delete old; archive=20
macro   pager   \eS   q1\ncollapse-alluntag-pattern~A\ntag-patter=
n(~P|~p|~Q|~F)~r3w\n;s\n Delete old; archive
folder-hook . 'save-hook . =3Dsave.%B'


I hope this helps!

-Andre

--bCsyhTFzCvuiizWE
Content-Type: application/pgp-signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9IaSwWkhBtALlJZ0RAmH0AJwNFjISgNyJefx73p0zHJqoW+11vgCgz5zl
YFXpZH/vr3VxVa3but8CgF0=
=GsN0
-END PGP SIGNATURE-

--bCsyhTFzCvuiizWE--



Re: Deleting portions of large mail folders

2002-07-02 Thread Rob 'Feztaa' Park


--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Alas! Wayne Chapeskie spake thus:
 How do the rest of you handle cleaning out really big mail folders?

Don't let them get that big in the first place! :P

Really. My mail setup looks like this:

feztaa@feztron:/home/feztaa/mail$ ls -R
=2E:
alfs-discuss  cron   lfs-dev   mutt-users wftl-lug
archives  fetchmail-friends  lfs-security  netmd-dev
blfs-dev  inbox  lfs-support   spam
blfs-support  lfs-chat   mutt-dev  wftl-announce

=2E/archives:
2001-11-bugtraq.bz22002-04-lfs-security.bz2
2001-11-inbox.bz2  2002-04-lfs-support.bz2
2001-11-marcel-gagne.bz2   2002-04-marcel-gagne.bz2
2001-11-mutt.bz2   2002-04-mutt.bz2
2001-11-rewt.bz2   2002-04-sent-mail.bz2
2001-11-sent-mail.bz2  2002-04-spam.bz2
2001-11-spam.bz2   2002-04-wftl-announce.bz2
2001-12-bugtraq.bz22002-04-wftl-lug.bz2
2001-12-important.bz2  2002-05-alfs-discuss.bz2
2001-12-inbox.bz2  2002-05-blfs-dev.bz2
2001-12-marcel-gagne.bz2   2002-05-blfs-support.bz2
2001-12-mplayer.bz22002-05-cron.bz2
2001-12-mutt.bz2   2002-05-fetchmail-friends.bz2
2001-12-sent-mail.bz2  2002-05-inbox.bz2
2001-12-spam.bz2   2002-05-lfs-chat.bz2
2002-01-blfs-support.bz2   2002-05-lfs-dev.bz2
2002-01-bugtraq.bz22002-05-lfs-security.bz2
2002-01-fetchmail.bz2  2002-05-lfs-support.bz2
2002-01-inbox.bz2  2002-05-mutt.bz2
2002-01-lfs-support.bz22002-05-mutt-users.bz2
2002-01-marcel-gagne.bz2   2002-05-sent-mail.bz2
2002-01-mutt.bz2   2002-05-spam.bz2
2002-01-sent-mail.bz2  2002-05-wftl-announce.bz2
2002-01-spam.bz2   2002-05-wftl-lug.bz2
2002-02-blfs-support.bz2   2002-06-alfs-discuss.bz2
2002-02-fetchmail.bz2  2002-06-blfs-dev.bz2
2002-02-important.bz2  2002-06-blfs-support.bz2
2002-02-inbox.bz2  2002-06-cron.bz2
2002-02-lfs-support.bz22002-06-fetchmail-friends.bz2
2002-02-marcel-gagne.bz2   2002-06-inbox.bz2
2002-02-mutt.bz2   2002-06-lfs-chat.bz2
2002-02-sent-mail.bz2  2002-06-lfs-dev.bz2
2002-02-spam.bz2   2002-06-lfs-security.bz2
2002-03-blfs-support.bz2   2002-06-lfs-support.bz2
2002-03-duplicates.bz2 2002-06-mutt-dev.bz2
2002-03-fetchmail.bz2  2002-06-mutt-users.bz2
2002-03-inbox.bz2  2002-06-netmd-dev.bz2
2002-03-lfs-chat.bz2   2002-06-sent-mail.bz2
2002-03-lfs-support.bz22002-06-spam.bz2
2002-03-marcel-gagne.bz2   2002-06-wftl-announce.bz2
2002-03-mutt.bz2   2002-06-wftl-lug.bz2
2002-03-sent-mail.bz2  2002-07-blfs-dev
2002-03-spam.bz2   2002-07-blfs-support
2002-04-alfs-discuss.bz2   2002-07-cron
2002-04-blfs-dev.bz2   2002-07-inbox
2002-04-blfs-support.bz2   2002-07-lfs-chat
2002-04-cron.bz2   2002-07-lfs-dev
2002-04-fetchmail-friends.bz2  2002-07-lfs-support
2002-04-important.bz2  2002-07-mutt-users
2002-04-inbox.bz2  2002-07-netmd-dev
2002-04-lfs-chat.bz2   2002-07-sent-mail
2002-04-lfs-dev.bz22002-07-spam

So as you can see, I have a bunch of mailboxes, and a monthly archive of
each mailbox.

My system may look cumbersome and hard to work with, but really it's not
because of these things:

* procmail automatically detects mailing lists and sorts them into
appropriate folders. I don't have a single procmail rule that is
specific to any one mailing list.

* mutt automatically detects mboxes and sets up the mbox-hooks
accordingly.=20

* because of the wonderful mbox-hooks, every time I leave a folder, all
the mails I read are moved into the appropriate archive folder.

* a script that I run from cron every month automatically compresses the
old mboxes that are archived.

So basically all I have to do is read my email everyday (not even -- I
just have to mark it as read if I don't want to read it), and my
computer does the rest of the work for me ;)

Each archived mbox contains a month's mail from that particular list;
obviously the amount of mail in each mbox depends on list traffic for
that month, but generally no mbox ever exceeds 1000 mails (though there
are at least a couple that have 1500 ;)

Oh yeah, and one really great part of this system: Since any read mail
in an mbox is automatically moved out, and mail that exists in an mbox
is by definition, unread. So when I'm looking at my index, the size of
the mbox becomes the new mail indicator: zero for no mail, nonzero for
new mail.

It works really well for me. YMMV.

--=20
Rob 'Feztaa' Park
http://members.shaw.ca/feztaa/
--
Lost: gray and white female cat.  Answers to electric can opener.

--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature
Content-Disposition: inline