vim #

As I imagine with many of these types of blogs, most of it has been written with vim or nvim. When I first decided to dive into linux, I also decided to learn vim, as I liked the idea of not having to switch to another window to edit a file when navigating around in the terminal.

In contrast to what most people will tell you, I found vim quite easy to pick up. It was my first modal editor, so that model took a bit of getting used to. Before vim, I used Brackets (I wonder how many people will have heard of this thing), Notepad++ and Visual Studio on Windows. When I switched to Linux, I switched to JetBrains Rider for school projects and used whatever default text editor comes with GNOME for other things. This got rather annoying as I wanted to learn to use the terminal as I basically immediately preferred it over graphical applications. So I found out about nano. I tried using it, but found it really annoying. The next editor I tried was vim. I had accidentally touched vim every now and then due always being close to a computer running linux somewhere while growing up. I had never understood it though. So one day, during a weekend, I decided to go through vimtutor. I had a lot of fun with it. The model of having keys have different functionalities depending on context immediately clicked with me. About a week later, I had stopped using GNOME’s default graphical editor and nano entirely. In JetBrains Rider, I quickly installed a vim plugin and got annoyed at its slight inaccuracies.

Then at some point, I found out I could make money with this “linux thing” with the right decisions. I was having way more fun with messing around with the odd nginx instance running on my school laptop than with any curricular topics. So I changed my career trajectory from game developer to linux person – for as far as that has proper term.¹ So during the last year of college, I barely typed any C# anymore and instead focused on various linux quirks and projects and such, which meant I didn’t have to touch Rider anymore.

nvim #

Over time, I started to look into plugins. And from plugins, I would find nvim. I like nvim. I like what you can make of it. I like how you can use it to make the perfect editor for you. It has a few problems though. It is configured in Lua and not exactly simple. This means that you will quickly have hundreds of extra lines to maintain in your dotfiles to configure your editor. And that’s without mentioning how dependencies are “managed”. The standard way is to download a program that will then clone a few dozen git repos on your behalf somewhere on your filesystem.

When moving to nix, this was one of the biggest pain points I had with it. So I found out about nixvim, which I used for a little while to at least not have to deal with another fucking package manager.

Helix – hx #

Then I found out about another editor named Helix. It had the features I was using in nvim – namely lsp and tree-sitter support and other customisability – without having to produce piles upon piles of Lua. Instead it is configured in toml; my least hated, standard configuration language². At first I was skeptical and didn’t want to have to bother with having to learn other keybindings. But I kept staring at it every now and then and one day decided to take the plunge and run :tutor. By the end I was convinced of its potential of being a usable editor. Then I took a look at home-configuration.nix(5) and saw that there was a Helix module that didn’t look too complicated. About an hour of configuring later, I managed to get it to do what I want and haven’t touched nvim much since then. There are a few features that I would like to see hx support one day for which I still used nvim every now and then – breadcrumbs and a decent spell checker – but that’s about it. A few months later, with a new point release of NixOS and nixvim fucking over half its config scheme again, I decided I’d had enough and uninstalled it. I still keep vim around for when codebook annoys me too much and I want a real spell checker.

misc #

I have also touched some different editors over the years.

vis is probably the most interesting of the bunch. I had a pile of rather old hardware on which I ran Apine because nothing else would run on it. Even vim would prove heavy for these machines, so I went with vis. I never really looked at it much besides that, but it looked quite promising.

Kakoune looked kind of interesting. In fact, I stumbled across it before I found hx. Then I tried it for a bit and decided that I couldn’t be bothered to learn other keybindings at the time. Whenever I touch it now, I find myself using my hx muscle memory, which works… some of the time. So I just stick to Helix.

Opinions and wrap up #

Due to my experience with editors, I have developed a few opinions on them which can be summed up in surprisingly little points. Any good editor should not be graphical, or at the very least should offer a text based alternative to a graphical interface. I don’t want to have to be near a computer to be able to edit files on it as I work over ssh connections a lot. Likewise, good editors are modal. You have limited keys on a keyboard, and the modal paradigm is the best way to make use of them without straining your fingers due to holding down key sequences for longer than is required for a single tap.