Introducing Helicopter system
More than a year ago I switched my main editor from Emacs to Atom. It’s nice and fast enough this day. It is a magnificent piece of software. It is the new better Emacs.
And I was happy with this switch, I’ve even installed atomic-emacs package to make transition smoother. But then I thought: hmm, since I’m switching an editor, I might try to switch my keymap as well. Because Emacs keybindings don’t make much sense. So I’ve tried the default ones.
But I wasn’t completely happy with it. Then I tried vim-mode, and I wasn’t satisfied either. Just because of the keys placement and the need to switch the modes. So I decided that’s it! It’s time to make a keymap which makes sense. And I made a quick draft how I thought it should be.
Then I have been using it for over a year, adding more and more keybindings over time, making it more sophisticated, changing the location of keys. I must admit I was pretty satisfied with it. But adding new keybindings to keymap file became a hassle. My system overgrew the supported technology. So I wrapped it into the package, tuned here and released it. You can check it on github here. I’ll just share the points from there here.
To make Helicopter system effective and powerful it is based on top of a few core principles.
1. Composability
One of the main goals of the project is to give a composable way to define keystrokes in a way that it would be mentally easy to learn them. Each keystroke consists of 2 main elements — method and argument. The left hand is responsible for methods and the right hand is responsible for its arguments.
You can see a few examples of resulting keybindings:
The defined keymap works via regular key events, there is no need for entering mode, like in vim. Although, mode as an addition might be added in a future.
You can see the whole keymap here.
2. Ergonomics & Semantics
All the keystrokes are defined with ergonomics in mind. The navigation keys lie literaly at your fingertips. And the more common the action you want make the easier it is to access.
Each key has a semantics behind it. So you don’t have to memorize all the weird keybindings, you just have to the remember base keys and next time you use it you will feel that it make sense. Many times you are going to guess the keybindings without ever using them.
The whole list of user experience principles you can see here
3. Different keyboard layouts support
From the day one we have a support for different keyboard layouts. No matter which keyboard layout you use, the keys stay at the same place. Me myself using programmer dvorak, I see how it can be important to have support for different keyboards.
4. Customizability
All the keybindings should be customizable. If the defaults don’t make sense for you, you would be able to change it. If you want to have the search button on another key — you should be able to do it. And of course nothing stops you to define your own keybindings in a usual way.
You can see how the keybindings structured here. And here is a resolving file for actions.
5. Scalability
Helicopter is not just a keymap, it is actually a system to define one. It gives you an ability to add new methods and arguments easily. There are still a lot of unbound keys left. So you can add support for your favorite packages without a problem.
Right now it can be used only on Atom. But it’s in the plans to support other platform too.
Helicopter system is still work in progress and it’s lacking many things, indeed. But it proved to be useful already. Anyways, developing a keymap system is a journey, and it’s an interesting one. And If you are the one who would want to make this journey together, join the project, and let’s rock the boat!█
