To deal with an average of 200 emails per day, I too use procmail to sort incoming mail into a dozen or more primary mailboxes, which in mutt are presented in prioritised order, so that if I don't get all the way through, at least the most important are the first to be seen.
Since nearly half the inflow is from two high-traffic lists, only part of which is interesting, I let procmail chuck out stuff I'm not interested in, triggered by subject line. That leaves about 100 where I at least read the subject line. After deleting what does not appear worth an investment of more time than required to read the subject line, I read the rest, and do one or more of: a) File in one of 1093 descriptively named mailboxes, for presorted future reference. (Sometimes in two, if different aspects are salient.) b) If there's a linux, embedded systems, gnu toolchain, or similar command-line winkle or usage gem, note it in my 350-odd page personal survival notebook. (Text file, with folding, using vim.) Delete email. c) If it's interesting enough not to delete, but warrants further thought, other reading, or some trial, then it goes into "todo". That avoids the psychological pain of sending it to /dev/null, but has approximately the same effect. (But does help to soak up some of the excess disk capacity we have these days.) d) And if a reply is warranted, delete the email, unless of compelling interest, if it is list mail. Let others store it. e) OK, I do sometimes leave emails in the inboxes, reflagged as unread, if it's nearly bedtime, and I'm too sleepy to deal with it now. Occasionally, it can help to read a technical issue twice before posting. ;-) On 03.05.13 16:49, Petros wrote: > Well, there is sometimes not the right time to look after something en > detail, so it has to be later. That works best of all when "later" is so late that a deadline has been passed, and the email can be deleted. > (And yes, as a newsletter editor I have to collect too). Once a newsletter issue has been published, perhaps most email in "pending" can be moved to newsletter_issue_xx_done, with no more than a cursory scan of subject lines, to rescue any carried over? (One finger on "tag", one on down-arrow, so it's just a case of going dit-dit-dah-dit_dah down the list, as fast as you can read, then tag-save to the other mailbox. Done. > There is also information scattered in several e-mails of a thread. > E.g. a cmp for the kid: > - one contains date and time > - a second a correction > - a third one a payment information > - a forth one a health form > .. Several alternatives: a) In mutt, and presumably also in other MUAs, it is easy to tag arbitrary emails in a mailbox index, and link them into a new kid-specific camp-centric thread of your creation. If you quickly send yourself an empty email with a summarising subject line, then link the tagged emails to it, it will be the head of the thread, so that when the thread is collapsed, all is presented as a single summary heading in that inbox. (In mutt, hit Esc-V to expand the thread, showing the collected messages.) Once done, tag the lot, and delete or archive as a unit. Minimum keystrokes, minimum time. b) Tag the component emails, then tag-reply, with quoting. Now you have the text of all the component emails in one, as quoted text. Email that to yourself, after deleting the other recipients. You'll have an alias, such as "me" to minimise keystrokes for that. (And if parts have different authors, that is preserved in the attribution for each of the multiple quotes.) Notes to yourself, or additional information (perhaps received by phone) can be added to this collation email before posting to yourself. If e.g. a "[keyword]" is added to the subject line (or another header added, e.g. by a command you add to mutt), and a procmail rule is provided, then it can be placed in a preferred mailbox by that means. Manually saving instead of send works as well. c) I always have a minimum of 4 xterms open, with email in one. Highlighting some text, and pasting into an open vim session in an adjacent xterm is convenient when it's going into a larger document. It might work in your collating case, if the result needs to be a matrix of prerequisite guff for a busload of kids. > They do not have to be in the same thread.. If I would have a pin > wall, I could make a "school camp" entry, and the related e-mails are > pointed to and the arrows say: "payment info", "date and time" etc. > > After the camp, there may be another event, and what was the phone > number of the camp organiser? Somewhere in the mail.. If there is a "camps" mail folder, then rather that just running egrep on a bunch of folders, to give a filename and one-line match, just run an email body search in the MUA, taking us to the whole email. (So long as we can remember one of the organiser's names, as it appears in the email, then I wouldn't expect to spend much more than 10-20 seconds on the search.) > Folders aren't good enough, I think. Tools maketh the man, I figure. > I am missing a visual way of help to find things. Mouse-rubbing is to my mind the most manual and inefficient way to muck with text that has been created. (But I'm told that the colours and curlicued fonts make up for that.) When I have completely lost track of where in 1093 mailboxes an email might be, a quick egrep on a likely string, redirected to a tmp file, opened in vim, then used as a navigation tool (by means of the "gf" go-file command) to "hyper-link" to each matching file, usually finds it quickly. Flipping back and forth between the list of hits, and the matching files, then hitting "n" in vim, to find the matching line, is one way. Utilising vim's "quickfix" feature to go straight to the line is another, if we have used "grep -n". (It'll probably be necessary to tweak the quickfix format for the use case, though.) Erik -- I have long felt that most computers today do not use electricity. They instead seem to be powered by the "pumping" motion of the mouse! - William Shotts, Jr. on http://linuxcommand.org/learning_the_shell.ph _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
