wxhaskell on darcs.haskell.org

Well, it's official. The wxHaskell revival is now underway. No promises on when the next release is coming out, but getting a binary release out the door is the first thing we're aiming for.

We'll now be using a darcs repository as our main development:

darcs get http://darcs.haskell.org/wxhaskell

We retain sourceforge for all our other interactions (bug tracking, file distribution, etc). We're adopting a darcs-project model of development -- gee, I wonder why -- in that mostly everything is darcs sent to the mailing list for community review and one person (that would be me) gets the job of pushing the patches in. My policy is that if one of the core wxhaskell team says it goes in, it goes in.

My personal objectives are to get the build system working better and wring out the Unicode stuff. Shelarchy has a patch which makes it compile with ghc 6.6, but does automatic install of wxcore... I'd prefer to have it so that you have a little more control over the process: make; make install; make wx; make wx-install). Hopefully, separating the wxcore and wx build stuff will make Cabalisation easier. If we don't know how to cabalise wxcore, at least we should be able to cabalise wx. As for the Unicode stuff... well, I haven't thought too hard about it yet. Will likely involve some way of testing things out thoroughly. Any thoughts on the matter?

Well, it's official. The wxHaskell revival is now underway. No promises on when the next release is coming out, but getting a binary release out the door is the first thing we're aiming for.

We'll now be using a darcs repository as our main development:

darcs get http://darcs.haskell.org/wxhaskell

We retain sourceforge for all our other interactions (bug tracking, file distribution, etc). We're adopting a darcs-project model of development -- gee, I wonder why -- in that mostly everything is darcs sent to the mailing list for community review and one person (that would be me) gets the job of pushing the patches in. My policy is that if one of the core wxhaskell team says it goes in, it goes in.

My personal objectives are to get the build system working better and wring out the Unicode stuff. Shelarchy has a patch which makes it compile with ghc 6.6, but does automatic install of wxcore... I'd prefer to have it so that you have a little more control over the process: make; make install; make wx; make wx-install). Hopefully, separating the wxcore and wx build stuff will make Cabalisation easier. If we don't know how to cabalise wxcore, at least we should be able to cabalise wx. As for the Unicode stuff... well, I haven't thought too hard about it yet. Will likely involve some way of testing things out thoroughly. Any thoughts on the matter?

wxhaskell on darcs.haskell.org

yaht (badly) imported

YAHT is now a part of the wikibook. It took me a day of scripting, plus a couple hours here and there. I'm pretty embarassed about the way I did it, mostly a bunch of dumb regular expressions (Text.Regex) mixed in with a hacked-up versiono of lhs2tex. Lhs2TeX only has a pseudo TeX parser, which is better than anything I could have come up with in a short time. The lack of an abstract syntax tree was a bit annoying, but then I just recursively ran the texparser on any strings that were in environments, and things were more or less ok. Two things I really handled badly were math (you can see where my regexps go horribly awry) and links (I could have come up with better smarts for this...) (*).

There'll be some cleaning up to do, but as far as I know, it's all there. Let the great Haskell Remix begin!

(*) I call the result "YahtSee", short for "Yaht converter"

YAHT is now a part of the wikibook. It took me a day of scripting, plus a couple hours here and there. I'm pretty embarassed about the way I did it, mostly a bunch of dumb regular expressions (Text.Regex) mixed in with a hacked-up versiono of lhs2tex. Lhs2TeX only has a pseudo TeX parser, which is better than anything I could have come up with in a short time. The lack of an abstract syntax tree was a bit annoying, but then I just recursively ran the texparser on any strings that were in environments, and things were more or less ok. Two things I really handled badly were math (you can see where my regexps go horribly awry) and links (I could have come up with better smarts for this...) (*).

There'll be some cleaning up to do, but as far as I know, it's all there. Let the great Haskell Remix begin!

(*) I call the result "YahtSee", short for "Yaht converter"

yaht (badly) imported

yaht sources!

Many thanks to Hal Daume III for the tex sources to Yet Another Haskell Tutorial. As soon as I have time to work on the import, the Haskell wikibook will include the entirety of YAHT. We'll do this in two phases, I think. First I'll create a subpage of the wikibook containing the original YAHT. People can continue to use and modify that version indefinitely, because hey, it's pretty damn good. The second phase will consist of us wikibookians mashing up our stuff with YAHT stuff. Lot's of borrowing, moving, deleting and debating. It might come out great, best of both worlds, or it might just end up being horribly clumsy, but it'll be a worthwhile experiment!

Many thanks to Hal Daume III for the tex sources to Yet Another Haskell Tutorial. As soon as I have time to work on the import, the Haskell wikibook will include the entirety of YAHT. We'll do this in two phases, I think. First I'll create a subpage of the wikibook containing the original YAHT. People can continue to use and modify that version indefinitely, because hey, it's pretty damn good. The second phase will consist of us wikibookians mashing up our stuff with YAHT stuff. Lot's of borrowing, moving, deleting and debating. It might come out great, best of both worlds, or it might just end up being horribly clumsy, but it'll be a worthwhile experiment!

yaht sources!

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