
Quoting "Lev Lafayette" <lev@levlafayette.com>
Read every email once. Either act on it or delete it.
Act or ignore.
Yes, that's true.
Don't store thinking "Hmm.. this is interesting, I'll get back to that", except in the case when the storage is the action (e.g., you're writing a book or paper on the subject).
Well, there is sometimes not the right time to look after something en detail, so it has to be later. (And yes, as a newsletter editor I have to collect too). 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 .. 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.. Folders aren't good enough, I think. I am missing a visual way of help to find things. I will look at http://notmuchmail.org. Thanks Peter

On 3 May 2013 16:49, Petros <Petros.Listig@fdrive.com.au> wrote:
Quoting "Lev Lafayette" <lev@levlafayette.com>
Read every email once. Either act on it or delete it.
Act or ignore.
Yes, that's true.
Don't store thinking "Hmm.. this is interesting, I'll get back to that", except in the case when the storage is the action (e.g., you're writing a book or paper on the subject).
Well, there is sometimes not the right time to look after something en detail, so it has to be later.
I never delete mail (unless it's spam). But I do "Act or Ignore", or more realistically file under either "Needs Action" or Ignore.
Folders aren't good enough, I think.
Using multiple "labels/tags" on a single object are a better than storing in folders; the more the better, as it seems to aid search/retrieval.
I am missing a visual way of help to find things.
I've personally not looked into visual PIM solutions, but I'm sure they exist.
I will look at http://notmuchmail.org.
The method I'm using may not suit everyone, as it depends on Emacs Org-mode; As I'm reading mail (or news, or editing source), I can easily "annotate" a message using Org-mode's capture feature; which can be used for example, to create an actionable TODO item (Or re-file into an associated project) with a link back to the original message (or line number of source); then it just gets out of my way so I can continue with the task I was just performing. But I guess it doesn't really matter what tool you use, as long as you have a consistent approach. I've used Org-mode to implement David Allen's "Getting Things Done", but I could've just as easily chosen pen and paper, the methodology has been more helpful than the tool I've chosen. -- Joel Shea <jwshea@gmail.com>

Joel W Shea <jwshea@gmail.com> wrote:
The method I'm using may not suit everyone, as it depends on Emacs Org-mode;
Org-mode is excellent Incidentally, for those just learning Emacs (or for those of us who use it regularly and want to look something up), the reference sheet on the wiki has recently been updated: http://www.emacswiki.org/emacs/Reference_Sheet_by_Aaron_Hawley this doesn't cover org-mode, as the latter is an external package. Org-mode is, however, available from the Debian repository.

Jason White <jason@jasonjgw.net> writes:
Joel W Shea <jwshea@gmail.com> wrote:
The method I'm using may not suit everyone, as it depends on Emacs Org-mode;
Org-mode is excellent
Incidentally, for those just learning Emacs (or for those of us who use it regularly and want to look something up), the reference sheet on the wiki has recently been updated: http://www.emacswiki.org/emacs/Reference_Sheet_by_Aaron_Hawley
this doesn't cover org-mode, as the latter is an external package. Org-mode is, however, available from the Debian repository.
GNU Emacs ships org, the same as it ships gnus -- thought it is (probably) developed in a separate repo. In fact, org is the biggest elisp file in the repo (except ldefs, which is auto-generated).

Trent W. Buck <trentbuck@gmail.com> wrote:
GNU Emacs ships org, the same as it ships gnus -- thought it is (probably) developed in a separate repo. In fact, org is the biggest elisp file in the repo (except ldefs, which is auto-generated).
Thanks for the correction. Debian still offers org in a separate package, perhaps a more recent version than that integrated into Emacs itself. Org-mode 8.0 was recently released but isn't yet in the Debian repository. A further feature of note that may be of interest to some, is its ability to export to OpenDocument Text (ODT) format in addition to LaTeX and HTML.

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

Erik Christiansen <dvalin@internode.on.net> wrote:
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's a good work-around for the absence of a "memorized commands" feature in most mail user agents. News readers typically have "kill files" that ignore articles based on thread, subject line or other user-specified criteria. A general statistical classifier such as CRM114 could also help to distinguish "interesting" from "uninteresting" messages (where both terms are relative to the individual user, of course). Then there are reputation systems that can classify mailing list/news articles based on ratings given by other readers with similar preferences. In general, better tools to distinguish the signal from the noise are desirable, especially in conjunction with protocols for which they haven't been well developed, such as RSS, Activities Streams (the new protocol on which pump.io is based), not to mention their proprietary equivalents.

Jason White <jason@jasonjgw.net> writes:
Erik Christiansen <dvalin@internode.on.net> wrote:
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's a good work-around for the absence of a "memorized commands" feature in most mail user agents.
News readers typically have "kill files" that ignore articles based on thread, subject line or other user-specified criteria.
Since I haven't weighed in yet: email to *me* goes into my INBOX; public mailing lists (and RSS feeds) go to gmane, which I read via gnus NNTP. That way ML stuff doesn't pop up in front of me unless I explicitly go "OK, break time, let's open gnus". Private (work) mailing lists get put in shared folders on the work mail server, which I look slightly more regularly than gnus :-) I used to run http://cyber.com.au/~twb/.bin/imapbiff to pop up in my GNU screen systray whenever I have stuff in =INBOX, but I keep breaking it and forgetting to fix it. Oh, looking at the source, I think I got huffy because IDLE v1 doesn't support idling over multiple folders at once, and I didn't want to go the k9 route of opening a separate TCP connection for each folder I wanted to watch, so I am sulking until dovecot implements the (currently draft) RFC to fix that.
participants (5)
-
Erik Christiansen
-
Jason White
-
Joel W Shea
-
Petros
-
trentbuck@gmail.com