Vim

 13 min read

 January 8, 2024

Vim is a free and open-source terminal-based text editor, prevalent on UNIX systems such as Linux. I've been using Linux off and on for the past few years, but switched to it full-time on my desktop 18 months ago. Most Linux users have at least a working knowledge of Vi (the core component of Vim), so why don't more people use it on the daily?

I must have spent 100s of hours in Vim, coding away and writing random stuff. But I've also spent 100s of hours in VS Code, on my Windows system. Not to mention 10s of hours each in editors like Thonny, Arduino, notepad.exe (that counts, right?), Notepad++, Replit, and MakeCode. So, why do I still love Vim?

This blog is a piece on Vim, a vehicle through which I can share some thoughts and ideas. Also, I have no experience with Emacs so won't refer to it at all. Enjoy!

My History with Vim

I'm not really sure when the first time I touched Vim was. Whenever I'd experiment with doing something on Linux (usually via CyberStart), the tutorial would probably use Nano and so I would too. And if I wasn't following a tutorial, I'd always resort to a graphical editor like gedit.

I'm pretty sure the first time I voluntarily used Vim was when I forced myself to learn it, when I committed to becoming a real Linux user. This was the summer when I also coded this website. So yeah, I had to learn Vim quick if I were to now spend 12 hours a day stuck in it!

Did I even force myself to learn Vim? Or was it because I needed an editor to write config files when I first installed Arch Linux and really began to hate Nano (it's ugly and the Ctrl key hurts my thumb)? I'll let you decide :)

Again, I'm fuzzy on the details but I think I used vimtutor to get a feel of how Vim works – I never completed it because that's just too much information for one (small) brain to absorb in one sitting. Then, I went straight into using Vim to code, which was certainly a bold move.

I remember being really slow but because I was pretty new to coding a website and writing configs, it didn't really matter. It turned a simple task from taking 30 minutes to taking 35 minutes as I Googled every 5th time I needed to do make an edit.

I honestly don't know how I stuck with it.

But over time, I became familiar with Vim and learnt plenty of shortcuts. A few weeks in, and I was really efficient. A few months in, and I fell in love.

A year and a half later, I still discover some neat new trick every now and then to boost my productivity by that extra 1%. The learning curve to Vim is pretty sus, and probably the main reason it isn't popular among non-nerds. I find it looks something like this (at least, it does for me):

I drew that graph at 2am using a mouse – it works, okay...

Here's what each bump on the graph means:

  1. Vim makes literally no sense. You're in this state of shock and confusion, completely unable to use Vim at any reasonable pace. Entering Vim makes you scared, the feeling that you may never be able to exit looms over you. You're like a dumb goldfish, trapped in this tiny bowl.
  2. Aha! It clicks and suddenly you can use Vim to do basic things. You learn how to exit and save. Slowly, you get better and more accustomed to this way of writing. Your efficiency picks up and coding feels just as fun as it used to be.
  3. Then, you plateau. You don’t really get any better. You kinda just sit there, using Vim and completing the tasks you need to using the small suite of commands you're comfortable with.
  4. Every now and then, you'll begin to crave a certain feature or want to make a process more efficient. So you do some Googling and find a solution – perhaps a plugin or new command. Boom, you've learnt that little bit more and are one tiny step closer to becoming the Vim ninja God we all strive to be.

Initially, my Vim config was pretty minimal, I didn't need much else. But at some point, I really wanted to experiment with GitHub Copilot and it wasn't working with vanilla Vim. I also knew that CSS colour previews weren't possible with my setup. So I made the leap to Neovim.

Neovim

Neovim is a fork of Vim that provides a few more features and has a much bigger library of plugins. Practically, it's pretty much the same as Vim. The reason there's so many plugins is because you can use Lua to write them, instead of just Vimscript - something that isn't possible on vanilla Vim. People love Lua and hate Vimscript, so naturally, Neovim got all the community love.

I've only ever used Lua and Vimscript when modifying config files, so I can't appreciate the differences. But the general consensus seems to be that Vimscript sucks (a lot), and Lua is a joy to code in.

My transition to Neovim was quick - I just copied across my .vimrc and tied it with a Lua file which existed only to enable GitHub Copilot. Now, my setup was just like before but with some added functionality.

I didn't want to jump to something like SpaceVim - I think distros add too much default customisation. Whereas the low-level, fundamental improvements that come with Neovim were just what I wanted, and nothing more (you'll soon figure out why!).

From now, I'm going to use "Vim" to refer to both Vim and Neovim. The subtle differences between them are irrelevant in the bigger picture - capturing the concept is what matters most and "Vim" does that just fine.

Why I Really Really Like Vim

I've used Vim a lot - as a scratch pad, to write content, and to code. I think this best summarises why I like it so much: it minimises the friction between me and the computer.

This is the ultimate goal for a lot of things, right? Buying a big monitor, buying a nice mouse, learning to touch type, customising your computer, carrying a portable laptop, and so on. These are all decisions made to help someone use a computer more efficiently. Some of these tools almost become an extension to your body, seamlessly connecting the human and the computer, essentially augmenting the power of the human and knocking a barrier between the two.

That is what Vim feels like.

Vim has now become an extension to my fingertips, allowing me to focus on what I'm doing and not how to do it. I don't even think about most of the commands I use, they just happen naturally. This is critical, the key that unlocks true productivity. It helps me get ever closer to transforming thoughts to results instantly. And who would say no to a tool like this?

Overcoming the initial struggle is the hardest bit of the process, especially if you have real work to do and learning Vim just slows you down. You have to really force yourself to learn it. But it's worth it in the end.

"We need an interface to translate our thoughts into the computer, and the keyboard and the mouse are a necessary evil for now. But if you chose a career of software development, you should strive to minimize the friction that interface introduces." - well put by a forum member. Perhaps the future holds mindreading interfaces, we're already seeing a glimpse of that with the help of AI!

Vim seems to never crash or break. Vim's behaviour is consistent and predictable which means I've never had to think about how to fix it or waste time restarting it. I know that when I need Vim, it won't crash and hold me back - like during the intense moments of Advent of Code (AoC). That reassurance is incredibly valuable.

Doing things with Vim is just... faster. Probably because it's a keyboard-oriented editor which means I don't waste time moving my hand between the mouse and keyboard. That may sound like a silly idea at first, but if you add the total amount of time spent doing this, it's probably quite a lot. Also, who wants the cursor taking up valuable pixels on the screen - especially when it covers some text you're trying to read/write/edit?! Much more importantly, however, when I think about doing something, I want to execute that action as close to instantaneously as possible. But the slight delay caused by moving my hand over to the mouse and back works against this. It's subtly infuriating and feels unnecessary (it is).

It's like animations. Whilst I appreciate a good animation, I don't want them appearing in my workflow. For example, changing desktops/virtual workspaces doesn't need an animation - once I've decided that I want to switch workspace, I want that to occur quickly and not wait for some pixels to swipe across a screen. It adds a break to my thought process and is potentially a bottleneck if I do it a lot.

My speed with using Vim is perhaps a bigger function of my touch typing skills - a keyboard is already like an "extension" to my body, and if I confine my text editor to the keyboard, I achieve the same effect for the text editor.

And the obvious point to make here, an increase in speed leads to an increase in productivity. So if I'm spending 10 hours a day in Vim coding 100s of lines of code, that productivity boost is significant. And especially during times where speed is key, like AoC, it becomes a game changer.

Oh, and do I need to mention how cool I feel coding in my terminal using Vim? If it makes me happy, that's yet another plus!

I love highly-customisable software, and my text editor is no exception. Vim is relatively straightforward to configure, and the fact that it's a bit bare out-of-the-box makes it that much easier. I'm sure you can guess why I like customisation - it increases my efficiency but also makes something simply look a bit nicer :)

The software should adapt to suit me, not the other way around. This is the essence of customisation.

The plugins available for Vim are vast - and writing my own doesn't seem tooooo difficult. I don't actually use many plugins, and haven't configured my Vim a huge amount. Probably because I'm lazy, but also because I don't have a strong desire for anything to be added (yet).

My config file is just 60 lines long, containing basic settings and whatnot. Vanilla Vim is almost good enough anyway, though I do wanna experiment with some sort of file tree plugin...

I think it's pretty easy to get stuck in the trap of spending countless hours configuring some software, and end up doing this so frequently that you never have the opportunity to get efficient using it. At this point, customisation is probably just a waste of time but some people do just like the act of customising, and I can see why!

I take a different approach - I'd customise something right after I install it, then if I want a specific thing at some point, I'd add that to the configuration. Sometimes I do stumble across a cool plugin or feature which I'll then implement into my workflow, but I never customise purely for the sake of it. This probably does limit my exploration and creativity as I miss out on the element of "randomness" critical to discovery. But it's all about striking a balance between doing work and wandering, trying to do enough of both.

What About Other Editors?

Admittedly, you can have most of Vim in any fully-featured IDE. Take VS Code, for instance - there's an extension to implement all of the Vim motions, and the motions are 80% of what makes Vim Vim. But there's still that other 20%.

Part of it comes down to the power of Vim. For some, the array of advanced features like macros and registers are an essential tool.

Another part of it is that VS Code is super heavy on system resources. It's just clunky software, yuck! It gobbles RAM and you could probably read a book in the time it takes to load. Whilst my computer is sufficiently powered, it's not got enough overhead to comfortably accommodate software like VS Code. It would ramp up my fans, and leave less room in the RAM for other programs.

In my experience, doing any action in VS Code comes with a small but noticeable latency, the frustration adds up over time. I recently coded an Electron app and did half of AoC in VS Code. For something like the Electron project, VS Code was quite slow to use. But when it came to coding for AoC, where I'm confined to a single file, VS Code wasn't all that different from Vim.

It's also unnecessarily hard to edit settings and configure VS Code - everything is hidden away and works against intuition. It took me a very long time just to add a hotkey to run Python files. When it takes this much effort to customise an editor, using it is simply painful.

The array of plugins and support for VS Code is phenomenal, though! It's trivial to find the extension you want and use it - and there are loads of great extensions that cater to a variety of workflows. The integration with GitHub Copilot is helpful, and the recent AI feature drops are genuinely amazing!

The tab system in editors seems to be quite popular, where you'd have multiple files all open in different tabs - like a browser. I don't like it though. It feels like an inefficient way to deal with larger projects with lots of files. Also, VS Code's tab system works in a way that I really can't get behind, and I don't look forward to digging through its settings to change that!

As much as I've bashed VS Code, it's still overall a really nice editor, just that Vim out-does it in almost every regard for me.

The other editors I've dabbled in all have their drawbacks too, and none quite match the lightweight-ness, configurability, efficiency, and extensibility of Vim. User-hyper-extensible software is awesome, but it seems to be few and far between.

Even as I write this blog, OneNote freezes (and crashes twice) and adds that little bit of friction between my thoughts and my writing. Vim's never frozen on me.

I can see an excellent use for other editors though, if it's suited for a very specific (and perhaps niche) workflow. Developing Android apps on anything other than Android Studio would probably be a challenge - unless you're willing to spend hours setting things up and configuring it. But then again, if this is not just a quick one-time project, you probably should be spending hours doing that for the sake of overall productivity.

Modern IDEs can be feature packed, and more importantly, ready to go out-of-the box. Some tools are really magical, and modern IDEs are one example - they can do some crazy stuff. So I think they certainly have their place, but they're still just a one-size-fits-all solution.

And a one-size-fits-all solution is never the best solution for you.

Conclusion

It took a while to grasp Vim and really get used to it, but I'm so glad I did. It's changed the way I code and has made me far more productive. Vim is everywhere so being able to use it is a valuable and evergreen skill, enabling me to remotely operate servers and Raspberry Pis effectively. There's still so much more for me to explore and learn about Vim, my journey has really only just begun.

VS Code, and others, are still really good editors, but I think Vim pushes itself ahead with its extensibility and speed - both the app itself, and the human using it. It has become an extension of me, dissolving another barrier and enabling me to enter my "flow state" and stay there. Vim kinda just has it all, and does it all.

PS: If you can, I'd really recommend trying out Vim; stick with it for a month and evaluate whether it's better or worse than what you're currently using. It's a big initial investment, but the returns add up. And if you're already using Vim, awesome! If you've tried Vim and don't like it, I'd genuinely be interested in hearing why so hit me up for a chat :)

copied!

failed to copy!