Gaurab Paul

Polyglot software developer & consultant passionate about web development, distributed systems and open source technologies

Support my blog and open-source work

Tags

Using theme specific keybindings in VSCode to improve productivity
Posted  5 years ago

I have been using VSCode as my primary editor for a couple of months. However it has been a recurring pain point for me that we have to switch back and forth between the arrow keys and primary rows when editing code. This post outlines a somewhat non-conventional approach for this by abusing the when clause of vscode keybinding configuration.

Prior state of the art

The most popular solution for this seems to be the vscode vim plugin, and I tried adapting to it despite not being a vim user. While I got comfortable with the primary vim keybindings in a week or so of continued used, I continued getting the feeling that it was not really well integrated with VSCode.

Along with general performance issues and lagginess, the biggest problem for me was that often when navigating and editing rapidly the keystrokes would be applied out of order. This really breaks the flow when rapidly typing and after a month of usage I started looking out for an alternative.

Turns out a very simple alternative is to simulate modal editing through VSCode themes.

Theme specific keybindings

While I liked vim’s modal editing, not being a longtime vim user, I kept longing for a visual indication when switching modes. A trivial solution here is to just use different vscode themes along with the settings cycler extension.

With this extension enabled, we can have a single command to switch between two themes:

Now, we can define keybindings that are active only in a specific theme using the when clause.

This is somewhat verbose because VSCode only allows json for configuration (which I think is a bad idea), but nevertheless it gets the job done.

Now, when we press ctrl+; and switch to Monokai theme, we can use h,j,k,l as our arrow keys.

We can of course extend this further and define more keybindings for selection, jumping to start/end etc.

Once arrow keys were no longer needed for primary navigation, I have been using them for switching focus across editors in different split panels and moving the editor around between split frames (a common but infrequent operation).

This has worked out quite well for me so far.