Transformation

Part 1: Quitting VSCode – the why and how

Table of Contents

  1. Moving forward
    1. Begone tabs
    2. Begone sidebar
    3. Begone uhh… not Vim

Part 0

Part 2

Anyway, let’s get to building a better version of VS Code. In this case, better means more keyboard focused and less cluttered. This section is intended to be taken as a step by step process. I’d recommend making these changes one at a time so you can adjust. Picture yourself as a boiling frog. The goal of making these configuration changes is to slowly adapt yourself to doing everything with your keyboard. It doesn’t actually have to correlate with a set of bindings from another editor or anything. Learning new bindings is not that hard. What’s hard is adapting your workflow.

In my experience from the many times I’ve had to relearn Vim, switching away from a mouse centric tab based workflow to something more focused feels suffocating at first. Before you adapt, it feels like you’re trapped in the file. This is drastically worsened if you don’t know how to switch files quickly.

The first step in our process is going to be getting rid of tabs. Tabs make sense for browsers where you want to build up a collection of sorts that you can work through in any order. In programming however, it just encourages multiple bad habits.

  1. In my experience tabs don’t get closed until there are so many tabs that it becomes unbearable. This clutters your workspace and slows down switching between files.
  2. Tabs allow you to get away with a subpar knowledge of your own codebase. Why learn the structure of your own code if you can just keep half your project open at once?
  3. The only real use for tabs is when you do need to refer to some other code as you write new code. Just use a split. It’s faster.

Here’s how you disable tabs:

"workbench.editor.showTabs": "single",
"workbench.editor.enablePreview": false,

I’d also recommend some more ergonomic key binds for managing splits and groups. This is what I personally use:

{
  "key": "ctrl+space q",
  "command": "workbench.action.closeActiveEditor"
},
{
  "key": "ctrl+space shift+j",
  "command": "workbench.action.moveActiveEditorGroupDown"
},
{
  "key": "ctrl+space shift+k",
  "command": "workbench.action.moveActiveEditorGroupUp"
},
{
  "key": "ctrl+space shift+h",
  "command": "workbench.action.moveActiveEditorGroupLeft"
},
{
  "key": "ctrl+space shift+l",
  "command": "workbench.action.moveActiveEditorGroupRight"
},
{
  "key": "ctrl+space k",
  "command": "workbench.action.focusAboveGroup"
},
{
  "key": "ctrl+space j",
  "command": "workbench.action.focusBelowGroup"
},
{
  "key": "ctrl+space h",
  "command": "workbench.action.focusLeftGroup"
},
{
  "key": "ctrl+space l",
  "command": "workbench.action.focusRightGroup"
},
{
  "key": "ctrl+space ctrl+k",
  "command": "workbench.action.moveEditorToAboveGroup"
},
{
  "key": "ctrl+space ctrl+j",
  "command": "workbench.action.moveEditorToBelowGroup"
},
{
  "key": "ctrl+space ctrl+h",
  "command": "workbench.action.moveEditorToLeftGroup"
},
{
  "key": "ctrl+space ctrl+l",
  "command": "workbench.action.moveEditorToRightGroup"
},

It’s quite a hell of a lot, but the idea is to allow me to move around splits and workspaces in a way that is inspired by Vim motions. You’ll also notice the ctrl+space prefix to each binding, which I use somewhat consistently across any binding which has to do with the editor itself instead of the text I’m editing.

Now that we’ve gotten rid of tabs, you might notice yourself spending a lot of time moving your mouse over to the file switcher to move between files. Let’s get rid of the temptation, and while we’re at it, all that sidebar clutter. This really forces you to make use of both ctrl+p and ctrl+tab to navigate between files in a thought-out and efficient way. Switching between files with the mouse is absurdly slow, but unfortunately monkey brains are also slow. The file explorer is always visible, and your keyboard based file switching mechanisms aren’t. We need to put them on equal footing, so that your brain can accurately assess which is faster (it’ll be the keyboard).

For this step, you’re going to need two extensions. The first is File Utils, which gives you commands to create, rename, and move files. Unfortunately, VS Code is pretty handicapped in matters of file management outside of the file tree. This extension is missing functionality related to the moving of directories as far as I can tell, but it isn’t a crisis to break out the terminal every once in a while. The other is Auto Hide, which adds the ability to auto hide the side bar/terminal on project open and whenever an editor is focused. Our intent is to only have the sidebar open if we literally must use it (e.g extensions), so this is perfect This is also necessary to avoid needing to manually hide the sidebar every single time you open a folder.

These are both relatively rudimentary to configure. Of course, I’d recommend some similarly easy to access keybindings for File Utils, but it’ll always be in the command palette. Here’s some additional JSON config. Line 1 is the main important thing. It stops the file explorer from auto opening and focusing a file whenever you open one.

  "explorer.autoReveal": false, //The main important line
  "workbench.activityBar.location": "top", //Reduces bar width when visible
  "workbench.sideBar.location": "right", //Bar moving is less likely to shift code

You’ll also probably want a custom keybinding for opening and closing the bar, for those rare occasions when it’s needed.

This is the part of the post that I can argue for the least objectively, but I think it can be a worthwhile step. If I’m honest, this whole process I’ve described has actually been all about that Vim energy. Whether or not you decide to go for Vim bindings is up to you (and requires little configuration advice from me). However, I would recommend these binds:

{
    "key": "ctrl+k",
    "command": "workbench.action.quickOpenSelectPrevious",
    "when": "inQuickOpen"
  },
  {
    "key": "ctrl+j",
    "command": "workbench.action.quickOpenSelectNext",
    "when": "inQuickOpen"
  },
  {
    "key": "ctrl+k",
    "command": "selectPrevSuggestion",
    "when": "suggestWidgetMultipleSuggestions && suggestWidgetVisible && textInputFocus"
  },
  {
    "key": "ctrl+j",
    "command": "selectNextSuggestion",
    "when": "suggestWidgetMultipleSuggestions && suggestWidgetVisible && textInputFocus"
  },

These will allow ctrl+j/k to work inside of both code suggestion boxes and the quick open/command palette menus. This means you have to do far less mental switching between arrow keys and Vim motions.