I should probably begin with the fact that this is wholly inspired by Steve Losh’s fairly popular article, “A Modern Space Cadet”, and you should read that before continuing.

Steve’s remarks about improving his environment are completely true for me, too, and I occasionally tweak and adjust my various config files (available on GitHub) to suit my needs.

### Hardware

While Steve objects to the notion of really cheap keyboards, I don’t as much. I find that they often type very comfortably, especially the IBM/Lenovo ThinkPlus Preferred Pro (a SK-8820), which I currently use in it’s PS/2 variant.

That replaced a Digital-branded RT6856T that originated with a DEC Multia, and on which I spent many years typing. I learned to type Dvorak on it, and it’s rather sad to see it go.

I also use the keyboard in my MacBook Pro, as well as in my ThinkPad X100e, both of which are very nice, although very short-travel, chiclet-style keyboards.

I’ve not had the opportunity to try a real mechanical keyboard. I don’t mind the softer feel of a rubber-dome keyboard, but I might consider switching if I do run across one and like it. I spent some time looking longingly at a Topre Realforce keyboard, but decided not to do it, probably against my better judgement.

### Software

I currently use a Mac, so Steve’s documentation for much of the stuff he does is straight-forward to follow and Just Works. I only use a few of the Modern-Space-Cadet features, though, notably Caps-Lock as Control/Escape (expanding on Caps-Lock on Control, which is trivial), and Shift as parens.

The tools Steve uses – PCKeyboardHack and KeyRemap4MacBook – only run on OS X. I spent a while half-heartedly searching for a tool to replace them on Linux, but there wasn’t any real urgency; Synergy let me use their behaviour onto my current ThinkPad X100e, so long as I used my main keyboard (which I do for most of my work anyway).

As I write this, though, I’m fighting Lenovo to get my new laptop (which should be arriving in negative two weeks), which won’t run OS X, and thus, I needed a replacement. Fast.

#### Caps Lock as Control

I already do Caps Lock as Control, even though some people think that’s a Bad Idea. I completely disagree with Xah Lee: all the reasons given in that article make absolutely no sense to me, because I don’t touch type properly (although I occasionally wish I did), I type Dvorak, and in my Emacs, I have ⌘ as Meta and ⌥ as Super (and I have the Windows key as ⌥ and Alt as ⌘ anyway), I do sometimes use my pinky joint to press Control_L (which I find to be rather painful and less useful).

That’s a trivial transform anyway; setxkbmap does the trick, and I’ll use a magic loadkeys call to rearrange my Linux console keyboard.

#### Control is also Escape

Tapping Control for Escape is really nice, especially as I have God-mode in my Emacs. It’s kinda Vi-esque, but makes it much easier to think in Emacs. I use it occasionally outside Emacs, but it’s a superb keystroke.

To do this, though, I need a tool that lets X do stroke/hold differentiation. And I found one: xcape, which describes itself as a utility to “configure modifier keys to act as other keys when pressed and released on their own.”

$xcape -e 'Control_L=Escape'  Perfect! #### Better Shifting This fix would be truly sublime if it worked at all well for me. I barely use the correct fingers to the correct keys anyway – my left hand is fine, but my right hand wanders a lot, which I’m trying to rectify – so this fix is essentially unhelpful. #### Shift is also parens I use xcape again for this: $ xcape -e 'Shift_L=parenleft;Shift_R=parenright'


Under exotic circumstances (Xpra, for instance), I get shift-keys producing 9 and 0 for no obvious reason. Also, when I run it in a VM, and the host has this already enabled, it’s trivial to enter (( or )) with one keystroke.

I should also point out that I use one xcape instance to do this, as it supports modifier expression chaining.

#### More Modifiers

If I needed more modifiers (like configuring up a Hyper key like Steve’s) I’d use xmodmap to connect one of my keys to the appropriate X modifier.

That’s one of the really nice things about X: it’s so overdesigned. You can have twelve modifiers on your keyboard. You can press all 64 buttons on your mouse at the same time. You can have screens of arbitrary dimensions or resolutions. You can do this all over the network.

You don’t have to resort to silly things like multiple layers of keyboard mangling, because the X server can do all the magic itself.

And in any case, for the majority of cases, I can get away with the existing modifier set, mainly because …

… I use the menu key as a Compose key.

The notion of Compose keys are brilliant. I really like the notion of pressing a key, typing a sequence of characters, and out pops a pretty Unicode character. However, the default sequences in X are immensely silly, and in any case, there’s already an RFC for this.

RFC 1345 exists to specify a simple way of entering Unicode characters, and it’s a crying shame that Compose keys don’t use it, when this is precisely what they’re useful for. Vim and Emacs both support entering Unicode characters using RFC 1345, so why not extend this courtesy to the whole X server?

I haven’t found any Compose mappings on the Internet so far, so I wrote a Perl script that generates a Compose mapping file from the RFC 1345 spec. This becomes my ~/.XCompose, and I’ll use uim as an input method to replace the truly ancient XIM.

I don’t do this yet. I’ll be trying this when my new laptop arrives, as some of this I simply can’t test in a VM with one keyboard set.

I know some Emacs users who have menu mapped to M-x, which is, in a way, useful; I only know a fair few tools through their full function names, but since I can type just fine as is, I see no point in wasting a key on a chord.