Keyboard layers

The most basic thing, without which I can hardly find my way around the system any more, is keyboard layers.

I went through different approaches but settled on this pairing:

Karabiner + Hammerspoon

Karabiner-Elements makes the “input hardware” predictable:

it decides which physical key turns into what (tap/hold, a hyper modifier, virtual F keys, rules per layout).

Hammerspoon turns these signals into actions:

launching and focusing apps, managing windows (moving, layouts, moving between monitors, restoring sizes), window navigation, media control for specific apps, system things and quick commands usually hidden in menus. And most importantly, these aren’t just bindings but logic and context (state checks, focusing the right window before an action, delays, fallbacks, scenarios). Hammerspoon also works as a local server for me: I bring up a small HTTP endpoint and can trigger my commands remotely (for example, from Shortcuts on other devices). All in Lua, no magic and no UI mazes.

Why I chose Karabiner + Hammerspoon.

I tried various ready-made solutions, but they almost always have the same problem: I get exactly the set of features the author came up with. That’s fine as long as your scenario matches the “average user”. But as soon as layers, context, non-standard rules, reliable fallbacks and your own logic for windows and media come in, you run into the limits of the interface and the philosophy of a particular program.

Here the approach is different:

• Karabiner gives me control at the input level: I can turn any physical keys into clean signals and build layers so that typing doesn’t break and conflicts don’t occur.
• Hammerspoon gives me control at the behaviour level: I describe actions in code, add checks, context, delays and fallbacks, and get a result that works the way I need, not “the way the UI intended”.

In the end it’s not “yet another program with settings” but a platform where I set the rules myself. It’s for this flexibility that I chose this approach.