getting things done with mutt

Edit 2007-10-29: a reader asked me to add the gtd and mutt tags to this article. Thought I might take advantage of the situation to tidy up the article a little.

You've probably heard about Getting Things Done (GTD) and lifehacks by now. If not, it provides a simple, but non-obvious algorithm for human beings to stay on top of things in a stress-free and effortless manner. My implementation of the GTD spec is working pretty well, but it has one huge, gaping hole: e-mail. The following is a collection ideas for plugging the hole and adapting my favourite mail client, mutt, to be more GTD friendly.

basic next action labeling (X-Label)

My mail processing workflow is GTD inspired -- interestingly queues work better for email whereas stacks work better for real life -- but one major flaw is that when I save a message to =ACTION. The problem is that I was using paper to write my actions down. Paper's great, but it's not very convenient for something which is inherently computer-based (it means dragging my notebook out of my backpack, for example). What I needed was some way to associate email messages with actions.

Fortunately, a fellow mutt user has made a small patch to add an onboard X-Label editor to mutt. This is almost perfect for annotating messages with Next Actions and Waiting Fors. It does not compile against the mutt [1.5.13] that's in MacPorts, but I have updated the patch and Portfile so that it does. I will put it on the web if somebody's interested.

The following should go into your muttrc, so that to set a next-action, you simply hit 'y':

bind  pager y   edit-label
bind  index y   edit-label

To make this more useful, I also add the following white on red highlighting so that the next action is the most visible part of the message:

color header white red    "^X-Label:"

Filing to =ACTION (user-input)

I currently have the following set in my muttrc so that Ctrl-A saves the current message in =ACTION and Ctrl-W saves it in =WAITING (=WAITING is problematic, a bit of a black hole).

macro index \Ca "<save-message>=ACTION"
macro pager \Ca "<save-message>=ACTION"
macro index \Cw "<save-message>=WAITING"
macro pager \Cw "<save-message>=WAITING"

What I would like to do is script it just a little bit more so that Ctrl-a asks me what the next action is, and then saves it in =ACTION. What I need is a mutt feature (maybe it already exists) which I call <user-input> (which basically means, wait for the user to type something and hit enter). Then I can extend my macros like so (pager ommited):

macro index \Ca "<edit-label><user-input><save-message>=ACTION"
macro index \Cw "<edit-label>WF: <user-input><save-message>=WAITING"

I guess saving a couple of keystrokes isn't that big a deal. I could just have a workflow where first I hit 'y', plug in my next action, and then I hit 'Ctrl-a' (this is what I do now). But it would be nice if this was enforced by my keybindings. Note that in order for this not to be horribly irritating, the macro system should stop processing the macro if the user hits 'Ctrl-c'. In other words, if I change my mind about setting a next action, it should just stop there and not file my mail for me automatically (which would mean I'd have to fish it out, etc)

Next Action counter

One thing I would like to have whenever I'm looking at my mail is to have a small, discreet counter telling me how many next actions and waiting fors I have. You know that bar on the bottom of the screen in mutt? That's where I'd put it, on the right. ----- Actions: 9 WF: 15 ----. A little reminder like that would be great!

Next Action preview

Another thing which might be useful is to be able to 'preview' a message, but only showing its next action. When i'm in index mode of mutt, for example, below that bar on the bottom of the screen, I would like to have one line showing me the value of the X-Label.

that's all!

That's all I have for now. Please comment if you have any other ideas or mutt-gtd tips.

Edit 2007-10-29: a reader asked me to add the gtd and mutt tags to this article. Thought I might take advantage of the situation to tidy up the article a little.

You've probably heard about Getting Things Done (GTD) and lifehacks by now. If not, it provides a simple, but non-obvious algorithm for human beings to stay on top of things in a stress-free and effortless manner. My implementation of the GTD spec is working pretty well, but it has one huge, gaping hole: e-mail. The following is a collection ideas for plugging the hole and adapting my favourite mail client, mutt, to be more GTD friendly.

basic next action labeling (X-Label)

My mail processing workflow is GTD inspired -- interestingly queues work better for email whereas stacks work better for real life -- but one major flaw is that when I save a message to =ACTION. The problem is that I was using paper to write my actions down. Paper's great, but it's not very convenient for something which is inherently computer-based (it means dragging my notebook out of my backpack, for example). What I needed was some way to associate email messages with actions.

Fortunately, a fellow mutt user has made a small patch to add an onboard X-Label editor to mutt. This is almost perfect for annotating messages with Next Actions and Waiting Fors. It does not compile against the mutt [1.5.13] that's in MacPorts, but I have updated the patch and Portfile so that it does. I will put it on the web if somebody's interested.

The following should go into your muttrc, so that to set a next-action, you simply hit 'y':

bind  pager y   edit-label
bind  index y   edit-label

To make this more useful, I also add the following white on red highlighting so that the next action is the most visible part of the message:

color header white red    "^X-Label:"

Filing to =ACTION (user-input)

I currently have the following set in my muttrc so that Ctrl-A saves the current message in =ACTION and Ctrl-W saves it in =WAITING (=WAITING is problematic, a bit of a black hole).

macro index \Ca "<save-message>=ACTION"
macro pager \Ca "<save-message>=ACTION"
macro index \Cw "<save-message>=WAITING"
macro pager \Cw "<save-message>=WAITING"

What I would like to do is script it just a little bit more so that Ctrl-a asks me what the next action is, and then saves it in =ACTION. What I need is a mutt feature (maybe it already exists) which I call <user-input> (which basically means, wait for the user to type something and hit enter). Then I can extend my macros like so (pager ommited):

macro index \Ca "<edit-label><user-input><save-message>=ACTION"
macro index \Cw "<edit-label>WF: <user-input><save-message>=WAITING"

I guess saving a couple of keystrokes isn't that big a deal. I could just have a workflow where first I hit 'y', plug in my next action, and then I hit 'Ctrl-a' (this is what I do now). But it would be nice if this was enforced by my keybindings. Note that in order for this not to be horribly irritating, the macro system should stop processing the macro if the user hits 'Ctrl-c'. In other words, if I change my mind about setting a next action, it should just stop there and not file my mail for me automatically (which would mean I'd have to fish it out, etc)

Next Action counter

One thing I would like to have whenever I'm looking at my mail is to have a small, discreet counter telling me how many next actions and waiting fors I have. You know that bar on the bottom of the screen in mutt? That's where I'd put it, on the right. ----- Actions: 9 WF: 15 ----. A little reminder like that would be great!

Next Action preview

Another thing which might be useful is to be able to 'preview' a message, but only showing its next action. When i'm in index mode of mutt, for example, below that bar on the bottom of the screen, I would like to have one line showing me the value of the X-Label.

that's all!

That's all I have for now. Please comment if you have any other ideas or mutt-gtd tips.

getting things done with mutt

back from Haskell Workshop / ICFP

Got back yesterday early afternoon. Have spent the weekend just being a lazy slob, something I tend to do right after a trip.

But need to get things into gear.

Still need to writeup the patch theory 2.0 discussion we had, mostly droundy, Igloo, lispy and some strategic insight from kosmikus (and me furiously writing notes on the laptop and asking questions of the style "I clearly have not been listening to the last 10 minutes of this discussion". You know the kind...

There be patches in queue too.

Other than that, I have bought myself my first laptop, an ultimate white Macbook. Was relieved that compiling darcs on it wasn't very hard (need to toss '-package mtl' into the Makefile, as Will on the mailing list found out). I was starting to find the lab's iBook G3 a little slow for my needs (mostly [re-]compiling darcs). Am installing Debian on a Parallels virtual machine as we speak. Plan to do Windows XP as well, although I am a bit worried about it not being fast enough for me to compile and play around with darcs. Other than that, the main blocker is that I don't actually own any Windows license keys. Perhaps Micrsoft would be generous enough to donate a couple of keys to the project? It might help us debug stuff, after all.

Actually what would be better is if some Windows gurus decided to join the project. Come on, Windows hackers, you want to be a darcs developer too and you know it!

Gah. Planet Haskell. It's so embarassing to think that people are actually reading this. I'm not sure what makes me more self-conscious, people looking at my code (GPL forever... or at least until I find myself employed by somebody that objects to it), or my English (I'm an almost native speaker, so that's not the problem). When I read myself, I hear a mixture of valley girl blended with remnants of my choppy Malaysian accent and sprinkled with a good dose of whining and uninteresting detail (today I ate cereal) for good measure. Sigh... hit that Publish button eric, and get it over with.

Got back yesterday early afternoon. Have spent the weekend just being a lazy slob, something I tend to do right after a trip.

But need to get things into gear.

Still need to writeup the patch theory 2.0 discussion we had, mostly droundy, Igloo, lispy and some strategic insight from kosmikus (and me furiously writing notes on the laptop and asking questions of the style "I clearly have not been listening to the last 10 minutes of this discussion". You know the kind...

There be patches in queue too.

Other than that, I have bought myself my first laptop, an ultimate white Macbook. Was relieved that compiling darcs on it wasn't very hard (need to toss '-package mtl' into the Makefile, as Will on the mailing list found out). I was starting to find the lab's iBook G3 a little slow for my needs (mostly [re-]compiling darcs). Am installing Debian on a Parallels virtual machine as we speak. Plan to do Windows XP as well, although I am a bit worried about it not being fast enough for me to compile and play around with darcs. Other than that, the main blocker is that I don't actually own any Windows license keys. Perhaps Micrsoft would be generous enough to donate a couple of keys to the project? It might help us debug stuff, after all.

Actually what would be better is if some Windows gurus decided to join the project. Come on, Windows hackers, you want to be a darcs developer too and you know it!

Gah. Planet Haskell. It's so embarassing to think that people are actually reading this. I'm not sure what makes me more self-conscious, people looking at my code (GPL forever... or at least until I find myself employed by somebody that objects to it), or my English (I'm an almost native speaker, so that's not the problem). When I read myself, I hear a mixture of valley girl blended with remnants of my choppy Malaysian accent and sprinkled with a good dose of whining and uninteresting detail (today I ate cereal) for good measure. Sigh... hit that Publish button eric, and get it over with.

back from Haskell Workshop / ICFP

koweyunstable

It's official. Today I begin my role as darcs unstable maintainer, thus switching from hobby-hacking to hobby-patch-and-bug-tracker-watching. We've have been planning this for some time now, as Juliusz has some hefty time constraints to deal with.

I'm somewhat worried about this, and would rather somebody more competent did the job, because I don't exactly have the same foresight or discipline in thinking about the consequences of patches. I'm really more an incremental improvements, add a small feature kind of guy. Oh well. No better way to learn, I suppose. Plus I get to feel all important and stuff ;-) But maybe now we should have a motto for the unstable branch, something like, "darcs unstable... and we mean it!"

Now need to become more organised so that I can stay responsive, while keeping this, the wikibook and the wxhaskell stuff a fun hobby, something to take my mind off but not get in the way of the thesis.

It's official. Today I begin my role as darcs unstable maintainer, thus switching from hobby-hacking to hobby-patch-and-bug-tracker-watching. We've have been planning this for some time now, as Juliusz has some hefty time constraints to deal with.

I'm somewhat worried about this, and would rather somebody more competent did the job, because I don't exactly have the same foresight or discipline in thinking about the consequences of patches. I'm really more an incremental improvements, add a small feature kind of guy. Oh well. No better way to learn, I suppose. Plus I get to feel all important and stuff ;-) But maybe now we should have a motto for the unstable branch, something like, "darcs unstable... and we mean it!"

Now need to become more organised so that I can stay responsive, while keeping this, the wikibook and the wxhaskell stuff a fun hobby, something to take my mind off but not get in the way of the thesis.

koweyunstable

Does Haskell hurt your brain?

Feel free to bitch about Haskell in the comments! I'm interested to see how one should go about writing the How to read Haskell tutorial, as well as the Haskell wikibook.

The tutorial is aimed at people who want to understand some piece of Haskell code they encounter, or who like to learn by example (and quickly find themselves lost). The wikibook is more aimed at people who are new to programming and who are said to have an easier time picking up Haskell than their l33t hacker friends (you know, not so much unlearning to do). Speaking of l33t hackers, maybe this would be a good chance to point out Haskell for C programmers...

Anyway, yeah so, if you've been turned off by Haskell because it's hard, weird or painful, let me know. Note that if I receive any comments at all, I'm somewhat expecting them to be about IO and monads. Those comments are welcome too, although I would like them better if you followed up with any insights about what make them hard for you to understand. Otherwise, what I would most like to see are the complaints about reading and understanding Haskell code.

Feel free to bitch about Haskell in the comments! I'm interested to see how one should go about writing the How to read Haskell tutorial, as well as the Haskell wikibook.

The tutorial is aimed at people who want to understand some piece of Haskell code they encounter, or who like to learn by example (and quickly find themselves lost). The wikibook is more aimed at people who are new to programming and who are said to have an easier time picking up Haskell than their l33t hacker friends (you know, not so much unlearning to do). Speaking of l33t hackers, maybe this would be a good chance to point out Haskell for C programmers...

Anyway, yeah so, if you've been turned off by Haskell because it's hard, weird or painful, let me know. Note that if I receive any comments at all, I'm somewhat expecting them to be about IO and monads. Those comments are welcome too, although I would like them better if you followed up with any insights about what make them hard for you to understand. Otherwise, what I would most like to see are the complaints about reading and understanding Haskell code.

Does Haskell hurt your brain?

eric shuts up at last (and dreams of tidyness)

Alright, I'm going to put my foot down and force myself to take the thesis more seriously. This means you should be

1. seeing me posting only before my 22:00 bedtime (eh... oops)
2. not be hearing from me as much (yay!).

reorganising our stuff

I wonder what it would look like if somebody got down to it and started tidying up the darcs hierarchy... I think I've talked about this, like, a year ago, but somebody on the channel (wisely) said that we should wait until the conflictors stuff is finished... Hmm... but hypothetically, what would it look like? Maybe something like this?

Darcs.Support
         .Arguments
         .Flags
Darcs.Command (formerly DarcsCommand)
         .Add
         .Get
         .Record
Darcs.Repository (as in Darcs/Repository.lhs)
         .DarcsRepo
         .GitRepo
Darcs.Patch
         .Info
         .Match
Darcs.Util
         .External
         .FilePath
         .IsoDate

Darcs.Support sounds pretty stupid, but I don't know what else I'd call it. Basically for stuff which supports the Darcs.Command stuff (maybe it'd just go under Darcs, as in, Darcs.Arguments). This isn't the only way to do it, of course. Somebody else might have a better idea... but whatever way we choose, it'll be a lot nicer than what we have now. A bit more approachable, anyway.

Alright, I'm going to put my foot down and force myself to take the thesis more seriously. This means you should be

1. seeing me posting only before my 22:00 bedtime (eh... oops)
2. not be hearing from me as much (yay!).

reorganising our stuff

I wonder what it would look like if somebody got down to it and started tidying up the darcs hierarchy... I think I've talked about this, like, a year ago, but somebody on the channel (wisely) said that we should wait until the conflictors stuff is finished... Hmm... but hypothetically, what would it look like? Maybe something like this?

Darcs.Support
         .Arguments
         .Flags
Darcs.Command (formerly DarcsCommand)
         .Add
         .Get
         .Record
Darcs.Repository (as in Darcs/Repository.lhs)
         .DarcsRepo
         .GitRepo
Darcs.Patch
         .Info
         .Match
Darcs.Util
         .External
         .FilePath
         .IsoDate

Darcs.Support sounds pretty stupid, but I don't know what else I'd call it. Basically for stuff which supports the Darcs.Command stuff (maybe it'd just go under Darcs, as in, Darcs.Arguments). This isn't the only way to do it, of course. Somebody else might have a better idea... but whatever way we choose, it'll be a lot nicer than what we have now. A bit more approachable, anyway.

eric shuts up at last (and dreams of tidyness)

wxhaskell / wxC

I have a new project! (Oh no). So one day, sort of randomly, J.O'D on haskell-cafe takes the intiative to a start a wxhaskell revival process, and naturally enough, I volunteered to help out. I have now been assigned the task of making sure the Unicode stuff works (which I'm interpreting mostly as figure out how to write a semi-automated eyeball test suite).

Of course, one of the first things I ask for is for wxhaskell to switch to darcs. This project has been first-hand experience for me why a distributed version control system is so useful: it keeps the bit-rot away. Darcs's patch-oriented nature would have allowed us to keep a Unicode fork of wxhaskell alive whilst waiting for the official maintainers to find the time to bring the project back to life. You can't blame them... people are busy, right? The situation we faced with wxhaskell was one where Unix patch was piling on top of Unix patch; it was getting a little messy and annoying. This was exactly the kind of situation where easy forking and easy healing can keep a niche project alive.

I feel kinda silly. I've apparently had a tailorised darcs mirror of wxhaskell lying around since early July and just never went public with it. So tonight, after TD offered to host the darcs stuff, I finally dusted it off, and converted my Unicode mega-patch into 5 darcs patches and uploaded the whole deal on my homepage. I'm not linking it, because it's really supposed to be temporary. But the rest of the wxhaskell revival team know about it. So it's moving!

wxC and SWIG

SS on the wxc list has suggested we switch from handwriting our wxC stuff to autogenerating it with SWIG. It's been interesting discussing with him. Learned a bit from the process, and got a reminder (duh) that wxC is actually C++ code (of course, what else would it be?), only that it behaves exactly like C code on the outside. Anyway, long term project's looking interesting. SS says that given enough configuration, we should be able to generate the wxC code directly, even including the kind of annotations that wxhaskell needs. But we also agree that this kind of thing is for the long term. Short term priority is to get the new wxhaskell and wxc out the door!

I have a new project! (Oh no). So one day, sort of randomly, J.O'D on haskell-cafe takes the intiative to a start a wxhaskell revival process, and naturally enough, I volunteered to help out. I have now been assigned the task of making sure the Unicode stuff works (which I'm interpreting mostly as figure out how to write a semi-automated eyeball test suite).

Of course, one of the first things I ask for is for wxhaskell to switch to darcs. This project has been first-hand experience for me why a distributed version control system is so useful: it keeps the bit-rot away. Darcs's patch-oriented nature would have allowed us to keep a Unicode fork of wxhaskell alive whilst waiting for the official maintainers to find the time to bring the project back to life. You can't blame them... people are busy, right? The situation we faced with wxhaskell was one where Unix patch was piling on top of Unix patch; it was getting a little messy and annoying. This was exactly the kind of situation where easy forking and easy healing can keep a niche project alive.

I feel kinda silly. I've apparently had a tailorised darcs mirror of wxhaskell lying around since early July and just never went public with it. So tonight, after TD offered to host the darcs stuff, I finally dusted it off, and converted my Unicode mega-patch into 5 darcs patches and uploaded the whole deal on my homepage. I'm not linking it, because it's really supposed to be temporary. But the rest of the wxhaskell revival team know about it. So it's moving!

wxC and SWIG

SS on the wxc list has suggested we switch from handwriting our wxC stuff to autogenerating it with SWIG. It's been interesting discussing with him. Learned a bit from the process, and got a reminder (duh) that wxC is actually C++ code (of course, what else would it be?), only that it behaves exactly like C code on the outside. Anyway, long term project's looking interesting. SS says that given enough configuration, we should be able to generate the wxC code directly, even including the kind of annotations that wxhaskell needs. But we also agree that this kind of thing is for the long term. Short term priority is to get the new wxhaskell and wxc out the door!

wxhaskell / wxC

ssh stuff fixed

Fixed the ssh stuff on Saturday, making patches for sftp -q, sftp -b, and --disable-ssh-cm

Apparently, sftp has changed recently, by actually implementing the behaviour they've been documenting for some time, namely:

-b batchfile
Batch mode reads a series of commands from an input batchfile instead of stdin. Since it lacks user interaction it should be used in conjunction with non-interactive authentication.

That'll be man page I'm quoting there. Anyhow, that's part of the reason why issue273 was so weird. There's still other stuff mixed in there. For instance, I don't know why salty-horse's server randomly dies during or before scp when ControlMaster is enabled, nor do I know why scp doesn't give us something nice and useful, like an exit code for bad things afoot. But at least now things work like they should.

Also, my --disable-ssh-cm uses a little bit of evilness, namely, unsafePerformIO . newIORef to simulate global variables like you get in other languages. Eeewww... but it seems like the alternative would be to have a bunch of parameters everywhere, just to keep passing that DisableSSHControlMaster flag all the way down to the ssh calls. Lesser of two evils? I hope I know what I'm doing. #haskell seemed a bit doubtful at first, but basically told me it was ok, if I shouted NOINLINE at the compiler. And I hope this doesn't start a precedent of coding sloppily just because doing it right would be mildly inconvenient. The "global" variable is write once, read many, I figure. It's practically a constant, so it couldn't really hurt, could it?

no query cat

I tried looking at query cat today, but didn't get very far. I think I ought to see what DiffCommand does when you pass it file(s) as an argument.

guilty darcsing

Also, I've been rather active on #darcs and on the bug tracker lately. No, no, I'm not trying to take over the bug tracker (though I suppose other darcsers would be happy to have somebody take charge of it), nor have I been specially assigned to the job. It's just that things are going kinda badly at work. That is to say, I have to write up my yearly progress report, which is kinda hard (though not as bad as writing a paper), and so I just end procrastinating a lot... So as soon as I get my act together workwise and start disciplining myself again, my darcs activity should reduce to pre-July levels. Anyway, that's the general idea. If you see me talking, like a WHOLE lot on mailing lists, it probably just means I'm trying to avoid something important.

Fixed the ssh stuff on Saturday, making patches for sftp -q, sftp -b, and --disable-ssh-cm

Apparently, sftp has changed recently, by actually implementing the behaviour they've been documenting for some time, namely:

-b batchfile
Batch mode reads a series of commands from an input batchfile instead of stdin. Since it lacks user interaction it should be used in conjunction with non-interactive authentication.

That'll be man page I'm quoting there. Anyhow, that's part of the reason why issue273 was so weird. There's still other stuff mixed in there. For instance, I don't know why salty-horse's server randomly dies during or before scp when ControlMaster is enabled, nor do I know why scp doesn't give us something nice and useful, like an exit code for bad things afoot. But at least now things work like they should.

Also, my --disable-ssh-cm uses a little bit of evilness, namely, unsafePerformIO . newIORef to simulate global variables like you get in other languages. Eeewww... but it seems like the alternative would be to have a bunch of parameters everywhere, just to keep passing that DisableSSHControlMaster flag all the way down to the ssh calls. Lesser of two evils? I hope I know what I'm doing. #haskell seemed a bit doubtful at first, but basically told me it was ok, if I shouted NOINLINE at the compiler. And I hope this doesn't start a precedent of coding sloppily just because doing it right would be mildly inconvenient. The "global" variable is write once, read many, I figure. It's practically a constant, so it couldn't really hurt, could it?

no query cat

I tried looking at query cat today, but didn't get very far. I think I ought to see what DiffCommand does when you pass it file(s) as an argument.

guilty darcsing

Also, I've been rather active on #darcs and on the bug tracker lately. No, no, I'm not trying to take over the bug tracker (though I suppose other darcsers would be happy to have somebody take charge of it), nor have I been specially assigned to the job. It's just that things are going kinda badly at work. That is to say, I have to write up my yearly progress report, which is kinda hard (though not as bad as writing a paper), and so I just end procrastinating a lot... So as soon as I get my act together workwise and start disciplining myself again, my darcs activity should reduce to pre-July levels. Anyway, that's the general idea. If you see me talking, like a WHOLE lot on mailing lists, it probably just means I'm trying to avoid something important.

ssh stuff fixed