Switching back to Vim (full circle)

I use Vim since I started programming in 2011 but I have tried other editors and IDEs regularly. I used spacemacs for a few months, then doomemacs, got frustrated, and switched back to Vim. When I started development on Lona in 2019, I needed a debugger and some analysis tools, so I switched to VS Code and stuck to it until a few weeks ago when I encountered multiple problems that made it unusable for me.

When I started programming, taking a class in C programming, we were recommended to use Eclipse. I ran a very underpowered Lenovo Ideapad at the time which really struggled to run Eclipse. Also, the laptop had very low resolution, so half of my screen was covered with top- and sidebars.
One of the senior students introduced me to Vim and I was intrigued. I spent an entire weekend reading the Vim-Tutor and learned enough to be productive next Monday. From there on, I used Vim for the rest of my studies and in my first job.

Around ~2016 I got problems with RSI and switched from qwerty to dvorak, and since I use Vim non-graphical with the keyboard exclusively, I had to relearn basic movement and all keybindings I was accustomed to. I couldn't get used to the Vim dvorak mode, so I created a very customized Vim config that worked for me.

This set of basic movement and keybindings is very intuitive and convenient for me. So every time I try another editor or IDE, I spent the first hours recreating my Vim setup. With VS Code this worked surprisingly well, but it was not perfect.

VS Code Annoyances

Over-all my VS Code-setup was pretty usable, but there were some things that bothered me on a daily basis.

1. VS Code is not meant for keyboard-only usage

I used VS Code with vscodevim, which emulates all aspects of Vim I cared about. It is highly customizable, so it took me only a few minutes to recreate my dvorak setup. So I got Vim-like movement and modes for text files in VS Code, but only for text files.

Like Vim, VS Code supports buffers and tabs for all sorts and things, but the Vim bindings would only work (correctly) in actual files. This meant not all aspects of VS Code could be controlled with the keyboard, and I came into situations regularly where a tab or popup opened, and the only way to interact with it was using the mouse.

2. vscodevim is not Vim

vscodevim is really close to Vim, but a few things are off. Nothing major, and most of the time you can’t pinpoint the issue, but sometimes things just feel weird.

For example: When selecting a visual block, DEL does not work like in Vim, you have to press d to remove it.

This is not wrong, and precisely what Vim Tutor teaches you, but this works in Vim and previously I wasn’t even aware that I am used to this behavior.

Actual Problems

1. Performance

VS Code is a chrome-app so basically you are typing into a browser. This gives VS Code great UI flexibility and many extensions make great use of it, but it comes with a noticeable performance penalty.

VS Code took a significant portion of my systems resources, and since I am working on a laptop with limited CPU cores, RAM, and cooling capability, it got either really slow or hot (or both).

3. Not meant for long sessions

On every system I use, I run very long sessions. I never shut down my laptop and only reboot it if necessary, and for the entire uptime, my Vim+Tmux setup runs. I like to think about my Tmux sessions like parts of my desk, where I place unfinished work. I like leaving things open, go to bed, and start where I left off. With Vim+Tmux that is no problem and works even on sessions running for weeks or even months.

With VS Code, this was always problematic. Editors that were open for a long time would end up using high amounts of RAM and getting unresponsive. Also, many extensions, vscodevim for example, have problems with long sessions. I ran into multiple strange cursor bugs, which only happen after 10+ hours and were hard to reproduce, and I got tired of restarting VS Code regularly.

3. Not really meant for working remotely

My work involves much end-to-end testing and docker. Both need much RAM, CPU, and network bandwidth. Therefore I use a Ryzen 5 based server for heavy workloads these days. Initially, I had the server set up only as a git remote and pushed my work onto it, always when I wanted to run a test (pretty much a poor-mans CI). My IDE and the source code remained on my laptop.

That turned out to be very inconvenient, because first: I have to run the test suite very often, and second: When I encounter a problem, my local debugger had no access to the actual running code that crashes.

I experimented with network file systems so I could edit remote files, and I tried VS Code in the browser, installing it on the server. Both approaches worked, but both were not as reliable as I wanted them to be. Also, they were a hassle to maintain since it’s outside the intended use case again.

Back To Vim!

The last problem was the one that made me switch back in the end. I dusted off my “old” Vim+Tmux setup and work remotely on my server 99% of the time now. No problems whatsoever.

It is pretty cool to carry a slim laptop with you, that has access to a Ryzen 5 with much RAM and wired internet, that can run a heavy workload without burning your legs in the process.

If you are interested in my setup, you can take a look at my configs here: https://github.com/fscherf/dotfiles