2025-08-30
First things first: This is a contribution to the first ever Vim Carnival, initiated by Hyde, and it is an honor to be part of it! A big “thank you” to Hyde for coming up with this great idea, organizing the carnival and hosting the first one!
When I first grappled with Linux in the mid-to-late 1990s, I was inevitably confronted with the question of which editor to use. There was a huge amount of editors to choose from, but I quickly learned that there were two editors which were mentioned much more than others, and those two editors obviously were vi and Emacs. I started playing around a little bit with Emacs, but soon I realized that it was not the right editor for me. I was looking for a tool which allowed me to edit text files, and nothing else. And Emacs definitely allows one to do a lot more than just editing text files.
Now it is certainly not my intention to revive one of the most famous holy wars ever. I completely understand if people use Emacs if this is the right editor for them (or any other editor, for that matter). For me, however, vi (or rather Vim at that time) turned out to be the right editor.
Its simplicity and minimalist appearance appealed a lot to me. I liked that the mouse played no role in using it. And I knew that there was no need for me to look any further.
I guess I was drawn to vi for the same reasons I was – albeit many years later – drawn to the OpenBSD operating system: I like things to be minimal. In particular, tools should do one thing only and do it well (the core of the Unix philosophy, by the way).[1]
Once I started using Vim, I never felt any desire to switch to another editor, and it is now my editor of choice since more than a quarter of a century (and I am so fond of it that I even maintain a dedicated vi page).
I do basically all my editing and writing in Vim, from e-mails to my PhD thesis (and, obviously, this very article as well). I also do all of my programming in Vim (no need for fancy IDEs). It is suitable for minor editing tasks just as well as for large writing or programming projects, and it has never failed me. It is fast – really fast –, and plain vi is available on basically every Unix installation out there – no matter what flavor of Unix or what age it is.
I love that it is a modal editor. In contrast to most other editors, pressing a key does not automatically make the corresponding character appear on the screen – it only does if you happen to be in insert mode. Otherwise, it is interpreted as a command. This allows for pretty easy key combinations for most simple and elementary commands (in contrast to non-modal editors, where one always has to escape entering characters, which necessarily leads to more complex key combinations). I also love that commands are very logical in a specific way; one could argue that they form some sort of a language. I will not dive into the details here; that would make for an entire new article (or two or three…). It has been claimed that editing text in Vim is an almost Zen-like experience, and while I feel that this does not really do justice to Zen, I completely get what is meant by that statement.
I do not use any plugins, although there is a huge ecosystem of plugins available for Vim (and Neovim even declares itself a “hyperextensible Vim-based text editor” on its website). I simply do not have any need for them. While there are certainly plugins which aim at improving the editing experience, my impression is that many plugins try to make Vim into something more than an editor. As mentioned earlier, though, that was one of the major reasons for me not to use Emacs. I do not want Vim to be more than an editor. I want to have an editor – no more and no less, period.
Actually, I do not even care much about many of the improvements of Vim over plain vi (Vim is “Vi IMproved”, after all…). For instance, I never use visual mode. While it may be helpful when one is new to Vim[2] – and in particular when one is used to GUI editors allowing one to mark text –, it is probably not the most efficient way to accomplish most of the things it is used for. In fact, I would argue that it would be a good idea to use plain vi for quite some time before (potentially) moving on to Vim. Many people probably do not even know how to accomplish things in vi without resorting to the improvements Vim offers. Yet, I am convinced that many of those improvements are improvements only in a superficial way. All this is elaborated extremely well in a reply on Stack Overflow, Your problem with Vim is that you don’t grok vi. I suggest reading it to everyone who is using Vim.
So, in a perfect world, I would be using plain vi instead of Vim[3], and actually this is what I did for a couple of years.[4] There are some reasons, though, why I switched to using Neovim for most things. One reason is that multiple levels of “undo” is in fact a real improvement over vi. Besides, I hail from one of those strange countries where people like to draw little dots above the letters, so Unicode support is practically non-negotiable for me. Also, I do use syntax highlighting, though I consider it by no means necessary (contrary to what I used to believe before using plain vi exclusively for a while).
My .vimrc
is very simple as well. While I am quite impressed by all the config
files one can find on the Internet which are hundreds of lines long, and while I
have a tendency myself to tweak config files way too much, I prefer to keep
things simple here as well. Setting a few options fully suffices to make Vim
behave the way I like.
Now, while one might get that impression, it is certainly not my intention to argue against using Vim and in favor of vi. While I do think that Vim has become rather bloated over time, I use it on a daily basis and am most happy with it. My point is to direct the focus on the beautiful core of Vim – which is pretty close to plain vi in my opinion, yet extends it in certain ways. I sometimes like to compare vi and Vim to C and C++:[5] There is this beautiful, rather small and well-defined, yet immensely powerful language C. And then there is C++, which extends C by far, adding feature over feature to it. Both are used heavily, and there are certainly reasons for both; but in most cases, I would rather use C instead of C++ (if I used them at all…).
So, coming back to the subject of this article, the question of how I use Vim: I use it mostly the way I would use plain vi, but I also happily make use of those extensions I find useful – which are rather few, though. While I have used Vim for decades, I am sure I only employ a small fraction of the possibilities Vim – or even vi – offers. I might become more efficient by putting work into learning more subtle and intricate features, but I feel no real need for it. I know that, should I need a particular feature, I will most certainly find it – if not in vi, then in Vim. Most of the time, though, I am happy using a select set of commands in a more or less efficient way.
There is so much more to say about Vim (maybe in the context of another Vim Carnival?), but for now, I will close my ramblings about Vim with one last observation: I do not just use Vim – I enjoy using it, a lot.
There are a lot of great text about Vim out there (for a selection, see my vi page), so I would just like to mention two particular ones here:
Seven habits of effective text editing by Bram Moolenaar, author of Vim.
There once was another nice article called “Grokking the Zen of the Vim Wu-Wei”, but unfortunately the original link is broken, and I cannot find it anywhere else. If someone does manage to find it, I would be grateful for the link.