Or not.
I use a Kinesis Advantage at work. They’re great for RSI-like symptoms, and they’re also programmable. You can remap keys on the fly, and put together macros. This suits me great.
Recently I realised that I never used capslock, and that I used Ctrl-A a lot (in GNU screen), so the obvious solution was to map capslock onto Ctrl-A, consistently saving me a keystroke. I could do this fine with a macro on the keyboard itself—but as it turns out, as long as you have at least one keyboard macro defined, the entire keyboard becomes sluggish and drops keys(!) at high typing speeds.
So, despite the promise of amazing programmability, the keyboard lets itself down here. I figured this shouldn’t be too hard to change in screen itself. Of course, I was wrong.
Capslock is a very special key in X, and it doesn’t appear to have any termcap-like name which I could bind to using bindkey in screen. Instead, you have to remap Capslock to something else entirely.
xmodmap lets you change key mappings—but you can only map one key onto another, not several. I’ll skip the entire story of how I got there, and give the solution instead:
xmodmap -e 'keysym Caps_Lock = Super_L'
Put this in your .bashrc or somewhere else where it’ll get executed on startup. Here we change Caps_Lock to instead behave as Super_L. If you actually use Super_L (winkey?), you’ll be in trouble.
XTerm*vt100.translations: #override \n\
<Key>Super_L: string(0x1b) string("z")
Add this in your .Xresources file. This causes Super_L to instead emit an escape key followed by ‘z’ in xterm. I picked that pretty much at random, but no existing VT100/ANSI escape codes seem to use that. We could just use Caps_Lock here (and skip the xmodmap), but that would result in the shiftlock still being toggled (in addition to our desired action).
If you don’t use xterm, add it to the appropriate resource.
bindkey -d "^[z" command
This goes in .screenrc, and causes the emitted escape sequence on Super_L (Caps_Lock) to act as the command sequence for screen.