yabai-stack-navigator

I’m primarily a Linux user these days, but due to work I’ve been using a Mac more regularly. One of my favorite things about Linux is i3, and I wanted to recreate my flow using yabai. While Yabai gets me most of what I miss from i3, there were things missing that added a little thrash when swapping between OS’s during the day.

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

First Attempt at a Custom Split Keyboard

I used to love the Microsoft ergonomic keyboard back in the day, but in recent years I switched away to mechanical keyboards. As fun as they are to type on, I found they weren’t the best for me posture wise. I decided to try to build my own custom split keyboard. As I didn’t want to spend the whole day messing around with building one (although one day for sure), I went with a Lily58 from Boardsource along with some Holy Pandas and these key caps.

VSCode Bindings to Mimic my VIM Setup

I meant to post this with my prior posts re: the VSCode File Explorer Menu extension. I wanted to write something detailing my current setup in VSCode that that attempts to mimic my VIM setup.

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

Command	Key	When	Notes
list.focusDown	j	explorerViewletVisible && filesExplorerFocus && !inputFocus	Goes to the next item in the file explorer.
list.focusUp	k	explorerViewletVisible && filesExplorerFocus && !inputFocus	Goes to the previous item in the file explorer.
workbench.action.quickOpenPreviousRecentlyUsedEditorInGroup	ctrl+e		This opens up a list of most recently used files.
workbench.action.gotoSymbol	ctrl+f12		This is technically from my Resharper days, but I decided to bring it over to VSCode. This opens a quick drop down of symbols in the file.
-workbench.action.openNextRecentlyUsedEditorInGroup	ctrl+tab		Opens the next tab.
-workbench.action.openPreviousRecentlyUsedEditorInGroup	ctrl+shift+tab		Opens previous tab.
workbench.action.toggleSidebarVisibility	, e w	filesExplorerFocus && !editorTextFocus	Toggles and focuses on file explorer.
selectNextSuggestion	ctrl+j	suggestWidgetVisible	Picks next autocomplete suggestion.
selectPrevSuggestion	ctrl+k	suggestWidgetVisible	Picks previous autocomplete suggestion.
workbench.action.quickOpenSelectNext	ctrl+j	inQuickOpen	Similar as above but for opening the next quick open item.
workbench.action.quickOpenSelectPrev	ctrl+k	inQuickOpen	Selects previous quick open item.
search.action.focusNextSearchResult	ctrl+j	hasSearchResult && searchViewletVisible	Picks next search result when search widget is visible.
search.action.focusPrevSearchResult	ctrl+k	hasSearchResult && searchViewletVisible	Picks previous search result when search widget is visible.

settings.json

Before	Commands	Notes
:	workbench.action.gotoLine	Jumps to specified line number.
leader r	editor.action.referenceSearch.trigger	Searches for references under cursor.
leader c t	workbench.action.closeEditorsInGroup	This is closes the “split”. I often will open a split, do some work, then trigger this command to close it back out.
leader s t	workbench.action.files.showOpenedFileInNewWindow	This is probably one of the few things from VIM I wasn’t able to fully replicate, I used to pretty regularly use “:tab split” in Vim to create a new tab in VIM which was in it’s own way like a separate workspace (especially with plugins like Ctrl-Space). The closest I’ve come to replicating this in VSCode is to just open the file in a new window. Unfortunately it opens the file in complete isolation so you lose all of the project’s context.
leader g d	editor.action.goToTypeDefinition	Jumps to type definition.
leader g i	editor.action.goToImplementation	Jumps to type implementation.
T	workbench.action.terminal.toggleTerminal	Opens up the Terminal.
leader j	editor.action.marker.next	Jumps to the next error/warning.
leader k	editor.action.marker.prev	Jumps to the previous error/warning.
leader t	workbench.action.toggleSidebarVisibility	Toggles sidebar.

VSCode Bindings to Toggle File Explorer

I published an extension the other day that tries to replicate the NERDTree menu and in the screen cast I did for the post I navigate to and around the file explorer menu via the keyboard without explaining how I setup my key bindings to do that.

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:

Attempting to replicate NERDTree’s menu in VSCode.

I’ve been a pretty happy Vim user for a while, but I wanted to give VSCode a try but often give up because I miss too much from Vim. This time around I made a list of things I wanted to be able to do in VSCode that I missed from Vim and one of the things on my list was the menu in NERDTree.

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.

Trying to write more

I’ve been thinking for a while I wanted to write more and realized I always struggled to maintain and curate a blog because I wrestled with mixing the personal with the less personal, so I decided to just create a blog for just tech thoughts and leave my personal blog over here.