Configuring VSCode as a Keyboard-Centric IDE

submited by
Style Pass
2023-01-25 16:30:10

One of my first posts on this blog in 2020 was about my experience switching from VSCode to Emacs for all of my text/code editing work. I still agree with all of the benefits to Emacs I wrote about back then, and my posts on Obsidian show my respect for org-mode as a format and the ecosystem around it – especially org-agenda. However, as you might have noticed when the file extension on my posts switched from .org back to .md, I’ve moved on from Emacs for now. But I’m happy with how I’ve moved my good habits back to VSCode. Spending time on config gave me more confidence in my ability to configure software I use to my liking, and make software work for me rather than make me work for the software.

At work, I’m always editing code while SSH’d into a remote machine. TRAMP with lsp-mode on a very large C++ codebase just had too much lag for me. Even accessing Emacs compiled with native-comp running on my remote machine had way too much input delay when waiting on responses from clangd or ccls, two C++ language servers. Now, it’s more than possible I was holding it wrong – I do have colleagues that work all day in Emacs. But it seems like my bad UX experience was due to the limitations of Emacs’s concurrency support – calls to language server were blocking other interactions with the UI. On the other side of the hedge, VSCode really just works. I can still type and otherwise interact with the editor while waiting for clangd to process a request. The remote SSH extension is the state of the art. The clangd integration was plug-and-play. And I’ve never experienced the lag that I was feeling every day on Emacs.

While I love the smoothness of the VSCode UI, I’m not a fan of how easy it is fall back on the mouse while navigating around the editor. My favorite part of the Doom Emacs distribution was the keybindings: it made me feel like I was playing chords on the piano when splitting panes and navigating around. While I’d configured Emacs to look and feel like VSCode in my original Emacs post, I ultimately got rid of the project explorer and visual tabs to embrace more Emacs-y buffer and project management. I found myself reaching for the mouse way more often when I moved back to VSCode, putting myself at risk for RSI and generally interrupting my flow. So I set out to make my VSCode configuration as close to my Doom Emacs setup as possible. There were only a handful of changes I needed to make:

Leave a Comment