Tom Insam

using utf-8 in irssi under screen

Firstly, tell your local terminal application that you want a utf-8
window. This is left to you, but under macos (which I use), right click
the window, select 'Window settings', pick the 'Display' option from
the drop-down, and pick utf-8 under 'Character set encoding'.

Next, when you start the screen session, pass the '-U' flag. This has
to be passed to a new screen session - you can't connect to an existing
one this way.

screen -U

Alternatively, you can turn on the utf-8 flag for a single existing
screen window by typing your hotkey (ctrl-a by default), then ':utf8 on'.
This is good if you don't want all of your windows to be utf now.

On the remote machine, make sure that the 'LANG' environment variable
is set to something UTF-8 like, for instance, I use

export LANG=en_GB.UTF-8

in my .bashrc.

Finally, you need to tell irssi to use UTF-8. Start it up in your new
utf-8 window, and type

/set term_type utf-8

Hopefully everything should work now.

Blotter 0.7

I discovered Cocoa bindings and verily, they are the greatest thing since sliced bread. Not that I'm very fond of sliced bread.

I've re-written Blotter from the ground up to take advantage of them - it's much nicer and more reliable now, although I totally changed the back-end format, so anyone actually using it and wanting to upgrade is in for a shock. I don't think anyone is, though. I mostly wrote it because I saw xPad and didn't really want to pay for something that seemed so trivial..

Anyway, Blotter 0.7 release - it's usable, although unhelpful the first time you start it. I use this app constantly, myself, so I like to think it's reliable. I've certainly never lost data to it. (I'm doomed now, of course.)

Update (about an hour later)

Curses, 0.7.1, with some small fixes.

Requirements for a bug-tracking system

Here's what I want out of a bug tracking system:

  • Must track bugs
  • I want milestones with bugs in, so I can see, for a given release, how many bugs are still open, who's working on them, and how close I am.
  • Speaking of which, a 'release' must be a first-class object, not just another sort of bug, with other bugs dependant on it. Releases are not bugs.
  • I want an intermediate stage of bug, between 'open', and 'closed', which is 'complete and ready for testing' - the tester should close the bug.
  • Has to be web-based, no platform-specific tools must be required..
  • ..but should also have a decent REST/something else API, so I can point a GUI tool at it when I want to. I'm a big fan of GUI tools.

Excerpts and Markdown

Markdown allows you to specify links [like this][1], and then specify the link target later in the file:

[1]: http://server/path/somewhere

This is really nice, and makes for very readable raw text, but it has a disadvantage when WordPress decides that it wants to automatically make an excerpt of something by truncating the raw text, then running it through the filter. You get a very ugly excerpt and lots of hanging links. The alternative, of course, is to process the text, produce XHTML, and then truncate it randomly, producing (probably) malformed XML. Not nice.

As a work-around, I've just removed all excerpts from this site - everything that ever appears should be full-text. It's not like I type a lot normally...