Specifically – I missed the way stacks worked in i3wm as it’s a regular part of my flow. In Yabai, there is stack support, but it seemed limited and required a few more steps than i3. To move between windows in Yabai, there are two different commands for moving between a windowed layout versus a stack layout (in i3 there’s just one).

There are some skhd bindings that somewhat work(link), but they don’t work once you hit the start/end the window stack. This makes quickly hitting the same navigation key to find a window a little bit more jarring as I’m used to being able to do that on Linux. In Yabai, I’d hit the key a few times and sometimes would realize I got stuck at the head/tail node.

To alleviate this, I wrote a small command line utility(yabai-stack-navigator). All the CLI does is let you call --previous or --next and it will move between windows(when not stacked), or move between stacked windows(and rotate to the other side when it hits the beginning or end).

More details at:
https://github.com/sendhil/yabai-stack-navigator

The first bit of settings are the ones I have setup in Keyboard Shortcuts (i.e. keybindings.json), the second set are the ones that are in the settings which are attached to VSCode VIM’s normal mode bindings (gist available here).

keybindings.json

settings.json

To open the file explorer I setup a binding through the Vim plugin. In order to toggle it closed, I had to set it up through the non-Vim key bindings as the Vim key bindings don’t trigger from the file explorer menu. To toggle the file explorer open, I use the following:

// settings.json

        {
            "before": [
                "leader",
                "e",
                "w"
            ],
            "after": [],
            "commands": [
                {
                    "command": "workbench.files.action.focusFilesExplorer",
                    "args": []
                }
            ]
        },

To be able to toggle this closed when the file explorer is open, I use the following:

// keybindings.json

{
  "key": ", e w", 
  "command": "workbench.action.toggleSidebarVisibility", 
  "when": "filesExplorerFocus && !editorTextFocus
},

I believe VSCode doesn’t match the ‘w’ here (i.e. “, e” will trigger the toggle), but I left it in so it’s easier for me to find if I’m searching this file for the binding.

The second part of my setup is the ability to navigate up and down the file explorer list and I do this with the following settings:

    {
        "key": "j",
        "command": "list.focusDown",
        "when": "explorerViewletVisible && filesExplorerFocus && !inputFocus"
    },
    {
        "key": "k",
        "command": "list.focusUp",
        "when": "explorerViewletVisible && filesExplorerFocus && !inputFocus"
    },

Here’s a quick screen cast showing this in action:

I looked around a little and couldn’t find anything similar so tried to play with the settings in VSCode. I was able to replicate some functionality (keyboard shortcuts to do different actions in the File Explorer view) but it didn’t quite feel the same. My muscle memory missed being able to hit ‘m’ while in File Explorer and then quickly select what I was going to do next.

As I’ve been trying to build more and also was curious about the internals of VSCode, I thought this was a good opportunity to build a plugin to help close this gap for me and learn a little bit more about how VSCode worked under the hood. A few days later and I’ve got my first published plugin vscode-file-explorer-menu (VSCode market place link here).

It’s a little hacky, but I’m pretty happy with it for now as it does what I missed from my Vim flow and am hopeful it’s useful to others.