How I switched from fancy editors to vim

I have been using vim for almost two years at the time of writing this blog post. It has become my primary editor for all text file editing needs, which include programming, which in turn includes developing whole projects. So this is a little story of how vim managed to hook onto myself.

For those who haven't heard about vim yet, it is a text editor born in the 90s with a minimal, textual user interface, and a keyboard-centric operation scheme. It has become many programmers and system administrators' text editor of choice and still is today given it is over 30 years old.

Before meeting vim

Previously, I used to program using normal editors and integrated development environments like everyone else. I first started with the Pascal language, using the Free Pascal IDE. Then I moved on to Java with Eclipse, to C++ with Visual studio, and to JavaScript, Python,... with Visual studio code. I discovered handy as well as fancy features from those, and loved them. However, I didn't actually make use of many of those features. Ones that I primarily used were creating, setting up and managing projects, debugging, simple refactoring, and creating and managing those projects' Git repositories. For other general text editing needs, I befriended Notepad++.

One thing I did notice while using the fancy editors (Notepad++ was not one) was that they tended to consume quite a bit of computer resources: RAM space, and CPU power. Considering I did not have fancy computers: first one was an old office desktop with 2 GB RAM and Pentium, second one was an Asus laptop with 4 GB RAM and 5th generation Intel Core i3 (which unfortunately got stolen, right from my home), third one was a 2010 Dell with also 4 GB RAM and literally first generation Core i5, they would become a significant load on the system. That was the necessary cost to pay for those fancy features though, so I accepted them along.

The encounter

As I got more experience in working with the computer in general and programming in particular, I started to use things on the command line more, one of which was Git. Normally at the time, I would pass a -m option to git commit to specify my commit message, but one day, I forgot to do so, and the console host window switched to this screen:

The commit message screen.

I did, of course, not know what to do, so I performed a Google search. A post from StackOverflow (I no longer remember exactly which one) revealed that it was the vim editor, and then I would press i to type in the commit message, then press Esc and type in :wq. That first encounter left me with an impression that vim was not a usual editor, and after that I searched how to change the commit message editor to Notepad++.

Another amount of time passed. One other day, I came across a chat where people talked about that the vim editor helped them to gain more efficiency editing compared to other usual editors. Having learned touch typing earlier and experienced its tremendous speedup compared to using my two index fingers, I decided I would give vim a try.

The learning curve

So I downloaded the vim installer for Windows from the official website, and went through the setup wizard, of course. The welcome screen hinted at the :help command, which I performed right away. The home page of the manual itself has a hint to "do the Vim tutor, a 30-minute interactive course for the basic commands". Thus I quit the editor using the command :q, which was also hinted in the welcome screen, and executed vimtutor, which opened vim and preloaded a text file which was the tutorial itself.

The vimtutor screen.

I had fun following the little lessons in the tutorial. I learned to use the hjkl keys to move around, instead of the arrow keys on the keyboard like I had been used to, and given that I had learnt touch typing, it didn't come as particularly awkward. However, I didn't remember all the commands introduced there, and I didn't think it was a necessary thing to achieve for the moment. So after finishing the tutorial, I returned to the help system AKA the manual, and proceeded to read the articles under the User manual section. I didn't try to grasp everything there either, not even visit all of the articles, but I felt like I have had enough in my mind to start actually using the editor.

I opened some code files to edit. In the process, it didn't take long until I realized there were some things that I wouldn't prefer that they behave that way. It made sense, I was still using the default configuration after all. So I read :help again, which instructed to create a .vimrc file in the home directory, which on my Windows laptop was C:\Users\Quang. Then I searched for the options I wanted to set, either from the manual or using Google, and put the lines to set them into the .vimrc file. For example, to show the current position of the cursor, I put set ruler, and then changed the display format to my own: set rulerformat=%20(%20(R\ %3l\/%L\ \ C\ %3v%)%), which would display as R 61/64 C 50. After a while and a bit over ten lines added into the file, the editor had become a bit comfortable for me to use.

After another while, I felt like the built-in options weren't enough to tailor vim's behavior and appearance to my liking. I could probably have written plugins in vim's own scripting language, so-called "vimscript", but I was more used to C, so I chose to hack into its source code. I forked vim's repository, cloned the fork and started digging around. Nicely enough, all the source code is in the src directory, and looking for spots to tweak didn't take very long. Some of the changes and features I added were:

Then I made some small shell scripts to invoke the build system (which is just make) to compile the code with my changes. After successfully compiling the editor, its files are copied to the editor's original install location, overwriting the old version.

So far, I have only ever had one plugin installed, fzf, which allows me to quickly search for things in source code trees. The rest, barring my source code customization, is pretty much pure vim.

In the process, I became aware there was also a trending fork of vim that is Neovim. However, after looking at its source tree, its build process was much more convoluted, involving many dependencies, which kinda defeats one of the points I chose vim in the first place: simplicity. So, I still keep using vim.

The new workflow

vim did manage to justify its praise to me, I have found that editing source code has become more effortless and efficient. Many editing actions are just done in a few keystrokes, compared to a variety of movements I would make in the other editors:

Unlike what many other do that they acquire various plugins or extensions to transform their text editor into approaching an integrated development environment, I only use vim strictly for editing the source code. To build, run, test, debug,... I use external tools, either invoked from the command line or in some cases having graphical interface. Thus, in some sense, it is the terminal that has become my development environment, rather than vim.

I also take a minimal approach to editing source code. As said previously, the only plugin I have installed is for searching. I do not use the built-in completion features, let alone full-fledged autocomplete plugins, as I find that just searching for the names, either in the documentations or in the source code, then typing that name out myself, is more intuitive (the touch typing skill helps a lot with this).

Probably needless to say, vim is really lightweight. From a cold start it takes about one second due to Windows shenanigans, but in subsequent invocations it starts nearly instantly. It only takes a few megabytes of RAM, and most of the time zero percent CPU time (the terminal I am using, Windows terminal, needs a few tens of megabytes, though). So I can leave the editor opened all day, pause editing in the middle and do any other thing on the computer without worry.

I still have the proper integrated development environments around, though: Eclipse for Java and Visual studio for C++. The debugging experience in the IDEs is simply something that can't be matched by a hardcore command-line session with gdb or so (though I do still use it from time to time). But their purpose is also only just that, presenting the debugging interface and nothing more. When I need to edit the source code, I simply click on the terminal's taskbar tab to bring vim's interface on top.

And Notepad++ is still my friend. It is useful for quickly double-clicking a text file in File explorer and scrolling through its contents, making a few adjustments when necessary.

Recap

So that was the adventure that brought me from the usual fancy editors to vim. My approach to it was kinda simplistic but also taken to as deep as modifying the source code. I hereby state the same message that has been said by many other members in the vim community: it may seem hardcore and daunting at first, but it will most likely drastically improve your speed, and perhaps also enjoyment, of writing code. And you are totally free to give your own approach different from my admittedly hardcode way, namely make use of as many plugins as you need to make your editor comfortable to you, and simply write vimscript rather than directly editing the source code. If you do decide to give the vim editor a spin, welcome, and have fun.

Discuss on Mastodon