Don't use Vim for the wrong reasons

Don't use Vim.md

Don't use Vim

Don't do the crime, if you can't do the time.

-- Anthony Vincenzo "Tony" Baretta

Vim is an amazing text editor. I love it. Really, I wouldn't organize a Vim advent calendar if I didn't. But, as amazing as it is, Vim is not for everyone. It can't solve all your problems, or be a TUI version of your favorite IDE, or make you a better programmer, or land you that dream job in the Bay Area. But Vim can help you be more mindful, focused, and efficient, as long as you approach it with the right mindset.

Don't get me wrong, I certainly welcome you to try Vim, but I'm not a proselyte. I don't thrive on newbies. I just want you to use the right tool for the job and not waste your—and anyone's—time on a fruitless quest.

Don't use Vim…

if you think you can get the features of your IDE without the weight and the sluggishness

While some recent advancements may hint at future changes in that direction, Vim currently lacks everything it would need to be considered/used as an IDE. From sketchy terminal integration, to being single-threaded, via the lack of anything resembling a proper internal plugin API, nothing in Vim can be leveraged to give you a convincing Integrated Development Environment.

From the user's point of view, an IDE is mostly a smart text editor with a bunch of utility windows tacked on. After all, the editor is the largest window, right? If that's all you see in your IDE then I guess you can be excused for believing all those "Vim as a $LANGUAGE IDE" posts from years ago.

Sadly, that's not how an IDE works at all. How it works, and the way it is architectured, can't currently be replicated in Vim. The best you can get is something that looks like your IDE—an editor window with tacked-on utility windows—if you squint hard enough, but you won't get a true IDE.

Additionally, IDEs are not bloated and sluggish and hungry for RAM and disc space because their developers are sloppy or want to mess with you or whatever. They eat resources and threads because they do a lot. Strip away everything that makes them IDEs and you get a lightweight editor. Add random incompatible IDE features to a lightweight editor that's not at all designed for that and you get a resource-hungry monster.

If you need IDE features, use an IDE.

if you want an experience entirely focused on your technology stack

Vim has quite the history with C but, other than that, it's not particularly suited for anything specific like front-end development, or Scala, or statistics, or functional programming, etc. It's a fine plain text editor that comes with minimal-to-good support for hundreds of languages out-of-the-box and can be extended with many plugins of varying quality if the built-in features and your own customizations don't cut it. But don't pay attention to claims that "Vim is the perfect $LANGUAGE IDE": they are usually followed by long lists of plugins that never work well together and often replicate built-in features the people behind those claims don't even knew about.

You can develop large C++ applications, work on React apps, build Go microservices, or write your CS thesis with Vim, and even have fun doing it, but thinking about Vim as a specialized C++/React/Go/LaTEX editor would be counterproductive.

if you think it's everywhere

Vim can be compiled for almost every platform/OS/hardware combination but it is not everywhere; hell, it's not on Windows, for starter, and Windows is the most widely used OS.

Vim is a vi clone and the whole justification for shipping your UNIX-like OS with a vi clone is that you want to ensure partial POSIX compatibility. Most Linux distributions use Vim for that while a few have been using vi since its legal status has been cleared. On BSD you generally get Nvi. On minimalist distributions used for embedded devices or containers you get BusyBox vi. Etc.

Also, your new favorite editor can be compiled with different features, sometimes-but not exclusively—grouped in meta features called "Tiny", "Small", "Normal", "Big", and "Huge", and the Vim you get by default, if any, is rarely the full-fledged version you would expect. Clipboard support, for example, is a pretty basic feature that is never built-in in default Vim and doesn't exist anyway in vi or Nvi.

What's (not) "everywhere" is slightly different interpretations of the standardized feature-set of vi, and vi is far from having all the bells and whistles that attracted you to Vim in the first place.

if you need to get up to speed in an afternoon

The learning curve is real and the productivity hit of learning Vim on the spot is even more real. It will take days to internalize the most basic stuff taught to you in $ vimtutor and it will take weeks or months to reach your previous productivity level. If you are serious about learning Vim, I recommend doing it on the side, progressively, without taking any of the shortcuts you would be tempted to take if you had to learn it on the spot.

If you are in a hurry, use a familiar editor/IDE.

if you only care about street credibility

If you are here because of fancy screenshots and the desire to look cool and belong to what you believe is an elite community then go away. That's a shallow attitude and the amount of time and effort required to even become a passable vimmer is guaranteed to turn you off sooner or later. Vim is only one tool among many for editing text and no one cares about it beyond our little coterie. And even then, most of us treat Vim as a power tool, not as a badge.

Your next recruiter, your next colleagues, your next crush won't care about Vim. Vim is not cool and you are not cool for using Vim.

if you can't afford the time and effort it requires to learn it

It will take time to feel comfortable and it will take more time to feel comfortable enough that you don't think about reaching to your previous editor. We are talking months before you can work at least as efficiently as before. Can you afford that? Are you OK with the idea of reading the fucking manual? Or are you on a hurry to show off your eliteness to your coworkers and don't have time to waste on boring reading?

Vim is a very powerful text editor that exposes an incredible breadth and depth of functionalities. Learning everything would take a lifetime and learning what you need right now will take months. If you lack the curiosity and the drive required to go past those months, then you should keep using your current text editor.

In general: if you are used to $FOO and consider switching to $BAR, learn $BAR before actually switching to it.

if you are not ready to change your habits and workflow

Vim is different. It has modes, it has commands all over the keyboard, it has tabs that are not tabs, it has different shortcuts than what you are used to, it lacks basic features and comes with incredibly useful ones you have never thought about, it's a TUI, it's incredibly dumb and incredibly smart at the same time, it puts you in the driver seat, it uses its own weird language for extension, it's old and buggy, etc.

The features you are used to may or may not be built-in or they may or may not require a plugin—or three. The way you are used to handle files may or may not match with Vim's built-in file navigation features. In any case, forcing your usual features and behaviors into Vim is an exercise in futility. You will get more value from learning it properly and leveraging its built-in features than from replicating your previous workflow.

An example of thing you might want to adjust to rather than fight against would be "tabs": Vim's tabs, called tab pages, don't work like other editor's tabs at all, so your usual tab-centric workflow must, at the very least, be changed to a buffer-centric one.

Besides, if you don't want to change your habits, why change editors in the first place?

if the job can be done better with another tool

sed, awk, cut, a quick bash one-liner, a simpler editor, an infinitely more powerful IDE, an actual IRC or mail client, an actual presentation program, some online CSV-to-JSON converter, etc. Specialized tools are very often better alternatives to Vim. Even pen and paper (or marker on whiteboard) can be better for many uses.

Yes, you have reached the "Vim everywhere for everything" phase but that's just a phase and you will get out of it, eventually.

How to approach Vim

Be open minded

What's different between Vim and other editors is why you are here so you should keep that open mind throughout your learning. Some of what Vim does will feel weird at first but, if you cultivate the right mindset, everything will eventually fall into place.

Be patient and mindful

There's a lot to learn but there's no point whatsoever in learning everything… and there's no way to do that in a single-seating anyway. In fact, people use Vim for 15 years and still learn new tricks regularly, when a new need arise or when they feel something they are doing could be improved. On that note, this advice from Bram Moolenaar's seminal "Seven habits of effective text editing" is absolute gold:

There are three basic steps:

1. While you are editing, keep an eye out for actions you repeat and/or spend quite a bit of time on.
2. Find out if there is an editor command that will do this action quicker. Read the documentation, ask a friend, or look at how others do this.
3. Train using the command. Do this until your fingers type it without thinking.

Read and experiment

Here are the three most important written resources to be aware of:

1. $ vimtutor is an interactive tutorial that teaches you the most basic concept. New users are expected to go through it as many times as necessary to internalize it as it covers everything a casual user should know.

2. The user manual is exactly what its name implies: a mandatory reading for every vimmer that touches on every feature present in your editor. Just read it if you don't like poking in the dark. Well, read it even if you do. :help user-manual is your gateway to knowledge.

3. The reference manual contains everything about everything. Using it is easy and explained in the first screen of :help. Whatever question you might have about Vim has its answer here so… always ask Vim first.

Ask

And when the answer you got from Vim is puzzling or when you have tried something based on what you found in the manual and it doesn't work as expected, you can ask fellow users for help:

• on Stack Overflow,

• on the vi and Vim stack exchange,

• on #vim on Libera,

• on Reddit.

In any case, be sure to prepare a minimum test case and explain what you are trying to do in order to avoid the XY problem.

Parting words

Vim is a complex program that lives in a bubble of its own. Its, shall we say, many peculiarities make it impossible to pick it up like one would pick up Atom or Sublime Text. Unlike those editors, Vim requires serious learning and unlearning before even being able to perform the slightest edit. Yes, it will take months before you use it more or less correctly and it will take decades to master it. Will it be worth it? I can't tell. It certainly has been worth it for me and many others while many more gave up or switched to other editors.

Learning Vim, or any other powerful program like Photoshop or Blender, requires a patience and a discipline that not everyone can afford and that's OK because not everyone has to learn those things. If you don't have the required discipline you won't reap the expected benefits.

---

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Permissions beyond the scope of this license may be available by contacting the author.

hell, it's not on Windows, for starter, and Windows is the most widely used OS.

What the hack dude, https://www.vim.org literally has a download link for Windows.

@leduyquang753 here is the full sentence:

Vim can be compiled for almost every platform/OS/hardware combination but it is not everywhere; hell, it's not on Windows, for starter, and Windows is the most widely used OS.

I think you missed the emphasis on "is not". Vim can definitely be on Windows but it is definitely not part of a default install.

Vim is not so powerfull as an IDE, but the vi keybinding/ edit modal mode are (as plugin in IDE). Daily I need to jump between Intellij(java), Visual Studio(c#) and Linux(less, vim). Using vi keybinding plugin make my life easier.

Started learning vim a a month back as a plugin in GoLand. I got used to it too much that I wanted to try vim8 as an IDE by it self. It was a frustrating experience and it is no way near an IDE. I have returned to using it as a plugin in GoLand.

@roskee, you can try neovim aka nvim. There are many pre-built configs. You can try astrovim and take it from there.

@roskee, you can try neovim aka nvim. There are many pre-built configs. You can try Astrovim and take it from there.

I use Astronvim. IMO it's even better than LunarVim. When things work, oh they work so well. When they don't? Oh, I wish I never used a pre-built config. When the pre-built config doesn't work, you're expected to know even more than with a set-it-yourself-config. By the time you're comfortable with fixing/modifying/using_effectively Astronvim, you could already do your own minimal setup config easily. So, although it's a good framework, I genuinely think that saying that it's easier is misleading.

EDIT: you never explicitly say that it's easier but it's implied.

nothing in Vim can be leveraged to give you a convincing Integrated Development Environment.

From the user's point of view, an IDE is mostly a smart text editor with a bunch of utility windows tacked on. After all, the editor is the largest window, right? If that's all you see in your IDE then I guess you can be excused for believing all those "Vim as a $LANGUAGE IDE" posts from years ago.

Sadly, that's not how an IDE works at all. How it works, and the way it is architectured, can't currently be replicated in Vim. The best you can get is something that looks like your IDE—an editor window with tacked-on utility windows—if you squint hard enough, but you won't get a true IDE.

I'd be curious to know what the part in bold refers to.

I've been using Vim for a few years, say 5, 4 of which to write C++ in a large codebase, and at the moment (say since a couple of years) I don't see what it lacks with respect to other editors. All my colleagues use VSCode, and my Vim setup doesn't give me any less than they have.

After all, how much I care about how it works, the way it is structured if I can't notice the difference as a user? I'm only interested in what I can and cannot do with it.

And I often find I have some advantage (undotree has saved quite a bit of time, if not often, sometimes, but VSCode doesn't have it yet). Probably this is a consequence of your point about discipline. There's so little discipline in using VSCode, that I don't use it and I'm the one who has to go around and tell people, when I help them during a call, to install FZF plugin for efficiently jumping from file to file, to install clangd to spare me their Indiana Jones-like search for the type definition, to learn the d*mn keybindings not to bother me with their imprecise mouse selections.

Ok, better to stop, it's becoming a rant off-topic with respect to your post. 😄

@Aster89

All my colleagues use VSCode, and my Vim setup doesn't give me any less than they have.

Well, of course, for VS Code is not an IDE, but "just" a text editor as well

@Aster89

All my colleagues use VSCode, and my Vim setup doesn't give me any less than they have.

Well, of course, for VS Code is not an IDE, but "just" a text editor as well

Not that Windows-ers using VS have ever shown me a staggering magic trick, other than a button to compile.

@Aster89

I'd be curious to know what the part in bold refers to.

I don’t have experience with heavy IDEs (JetBrains/IntelliJ), but the architectural features I’ve heard mentioned in this context before are:

1. Full access to the code base AST (allowing accurate AST-based refactoring in functions like “extract method”, as well as AST-based code navigation).
2. Full integration with a debugger/runtime (allowing you to e.g. visually “step through lines in the code” with the debugger inside the editor; then directly fix a bug and rerun only the fix to immediately test it).

These features can to some degree be replicated in Vim using e.g. LSP, TreeSitter (AST), and DAP (debugger). But I think the point is that this might still be less efficient and “integrated” than if you design the whole IDE around this workflow.

@Aster89 sorry for not responding. @jabirali pretty much nailed it.

The IDE promise is to provide SEAMLESS INTEGRATION between all the tools needed for software development, and more. This is usually done by adopting a "platform" architecture that facilitates said integration: each functionality is one piece of the whole, with the platform acting as a bus/broker/whatever between all of those pieces.

Such an architecture is fundamentally different from that of Vim, where even the notion of "plugin" was an afterthought. Vim is very powerful and useful but it is only a text editor. Its primary purpose is to allow users to edit text and everything in it is built around that. No "platform", no serious plugin API, no centralized package management, very basic language support for lots of languages, etc. Vim is as far of an IDE as it can be.

It has evolved quite a bit but not to a point where it can be considered as an IDE, plain and simple. If you want an "Integrated Development Environment", then look elsewhere. If you want a good text editor for your "Development Environment", then Vim might be it. Or not, there are maaaaany to choose from and Vim might not be for you after all.

I use vim key bindings in every place possible but I do not think using a terminal tool like vim, neovim, Astronvim, etc as an IDE is a good choice. Why waste so much time configuring these tools for the work they weren't supposed to be doing? Almost all IDEs now have vim key bindings that give us the typing experience we loved in vim.

@roskee All IDEs may have the keybindings, but do they actually work 100% like Vim? No, of course. For example, the VS Code vim extension has not matched my expectation in any sense possible.

@linhns You are right. They are far from being a 100% like Vim. And like you said I never liked the vim extension in VS Code and I always try my best to keep myself from going crazy over it 🤣 But Intellij (all the Jetbrans products infact) has a very good vim extension that works like charm. And to be honest, I would rather fight with the annoying VS Code vim extension than to spend enormous amount of time trying to setup Vim to be good for my programming language/framework.

Here is the situation we are in:

• If you know and use Vim very well, then all the Vim emulators have serious limitations.
• If you know and use your IDE very well, then nothing you can add to Vim can make it a convincing alternative.
• If you have a superficial knowledge of Vim, then Vim emulators might fit your limited knowledge.
• If you have superficial knowledge of your IDE, then you may be able to replicate it in Vim with various packages.

My opinion, as a relatively experienced vimmer who also uses IDEs but not in an advanced way, is that none of that is particularly satisfying. Consequently, my general advice has always been to use the right tool for the job™. In practice, it means that one must prioritize their needs.

I generally value the powerful editing provided by Vim over the smart language features provided by IDEs so I use Vim most of the time. But when I find myself in a situation where those smart language features matter, then I just use an IDE, without bothering myself with a Vim emulator.

when I find myself in a situation where those smart language features matter,

Would you mind giving a bunch of concrete examples? I just think I'm missing the point by simply not having a clear idea of what a very useful feature might be.

@Aster89 Two projects I have worked on in the past were tightly coupled with the IDE (Eclipse for the first—to the point of actually requiring a specific version—and IntelliJ for the second). In both cases I could still open files in Vim, of course, but the IDE was still required for so many things that jumping from one program to the other became a chore pretty quickly… and the Vim emulators sucked, so I simply used the IDE as-is. IIRC, in the Eclipse project, the imports were all "logical" so it was impossible to do gf or follow includes in Vim.

In those two admittedly extreme cases, access to the IDE's "smarts" had a much higher priority than the ability to use my lovely Vim.

Here is the situation we are in:

• If you know and use Vim very well, then all the Vim emulators have serious limitations.
• If you know and use your IDE very well, then nothing you can add to Vim can make it a convincing alternative.
• If you have a superficial knowledge of Vim, then Vim emulators might fit your limited knowledge.
• If you have superficial knowledge of your IDE, then you may be able to replicate it in Vim with various packages.

My opinion, as a relatively experienced vimmer who also uses IDEs but not in an advanced way, is that none of that is particularly satisfying. Consequently, my general advice has always been to use _the right tool for the job_™. In practice, it means that one must prioritize their needs.

I generally value the powerful editing provided by Vim over the smart language features provided by IDEs so I use Vim most of the time. But when I find myself in a situation where those smart language features matter, then I just use an IDE, without bothering myself with a Vim emulator.

This is the perfect explanation. I am in the second category currently. My limited knowledge of Vim and its key bindings has helped me a lot in being satisfied with Intellij's IdeaVim extension. What I would say, to all those who are having a hard time using Vim as an IDE, is that don't use Vim - use Vim extensions (since you are not an expert in Vim, you won't see much of an issue)

Ive spend an hour searching how to copy a line from VIM editor, had to use other editor instead to do such a simple task. I understand that was once a powerful tool, but nobody in their right mind uses vim for coding. Sorry, but such tools has no purpose in modern world. If you need to program open IDE, use Infrastructure as code approach so you don't have to open and edit files from server. And arguments that IDE is sluggish sorry, what computer you are running on? the 486? There are two reasons to use VIM, one is to show off, it will give you the same feeling vegans get when they say they don't eat meat or you learn it just for a hobby to understand how technology worked in late 80s.

@vytsci Vim is perfectly fine for coding, as long as your expectations match reality. Expecting Vim to be a free and lightweight feature-for-feature alternative to IntelliJ or whatever is setting oneself up for failure but expecting it to simply be a rather powerful but idiosyncratic text editor is much more realistic.

We would have a lot less Vim-related content on screen or on paper if people were not people :-).

it will give you the same feeling vegans get when they say they don't eat meat

I think this is just slighlty offensive to vegans, but that's ok, I guess.

@vytsci

Ive spend an hour searching how to copy a line from VIM editor, had to use other editor instead to do such a simple task.

Vim keybindings are very different from modern "standard" keybindings. Thus, you need to invest an hour or so learning how it works before you can use it productively (e.g. via the bundled vimtutor). Many people that do that end up preferring Vim keybindings afterwards; they're quite ergonomic (minimal use of Ctrl/Alt and mouse), composable (e.g. summarized here), and efficient (e.g. easy to automate repetitive actions).

• If you want a terminal editor that uses more "normal" keybindings, you would probably be happier using e.g. micro instead. Micro is also great, nothing wrong with preferring that.
• There are also Vim plugins for editors like e.g. VSCode. Lots of people enjoy modern IDE features but still prefer Vim keybindings.

use Infrastructure as code approach so you don't have to open and edit files from server.

I definitely agree that you don't need to learn Vim to work on servers. You can use the VSCode Remote Development extension. Or sshfs to mount it locally. Or use nano or micro on the server. Most people who still use Vim, use it because they actually prefer it.

Not all of us can "just use infrastructure as code" though. In my case, I work a lot on national HPC clusters where I don't have root access and definitely am not at liberty to change any infrastructure. The same goes for many people that work in e.g. banking or military.

This could be a template for articles like "file systems for smartphone users".

Vim9 is a good basis for IDEs. Looking from Emacs' side, Vim9script was long overdue.

I understand that was once a powerful tool, but nobody in their right mind uses vim for coding. Sorry, but such tools has no purpose in modern world.

Don't think of Vim as an application but as another way of typing. I agree that the vim editor itself can't be compared to the modern IDE's like VSCode and Intellij. But 'Vim typing' is one of the most popular techniques among developers - It has way more users than you might think. The vim extension on VSCode has more than 6 million downloads and the one on Intellij has over 15 million downloads. What I would recommend for you is to completely ignore the terminal vim editor and install the extension on your favorite IDE and enjoy!!!

All hail Vim!!!

I found a use for vim. I wanted to have an editor scroll and cycle through files automatically, for demonstration purposes. ChatGPT made me a vim script to do this in no time (which I modified/fixed slightly). So now I can just :source /path/to/script and see it go.

@roskee

And to be honest, I would rather fight with the annoying VS Code vim extension than to spend enormous amount of time trying to setup Vim to be good for my programming language/framework.

What programming language do you use that setting up vim makes you send enormous amount of time?

I use Neovim and hardly touch my config. It is much stable and hardly breaks. You can try it out if you want - Efficienvim (try the enhanced branch maybe you'll like that one more than the main branch).

Whenever I think I need to try out a new plugin (the well written docs of that plugin motivates me) I copy paste a minimal amount of the installation instructions (lua code). And configure only essential parts (setting up commands and keymaps). Also, based on the plugin ecosystem I have in my config, whenever a plugin breaks(rarely happens), I generally get the perfect solution in github discussions or some reddit post without getting too much time wasted.

If you use jupyter notebooks like something then that's a whole another story where vim is not even an option.

After exploring Vim episodically these weeks in 2024 it looks like this article is no longer actual in some parts.

It was written before LSP era. (Vim 9 plugin https://github.com/yegappan/lsp )
Vim9script started in 2019-2020 made Vim a unique editor with scripting in statically typed interpreted lang. Backward compatible.
It should be recommended to learn Vim in parallel with Vim9script, it makes it equal to Emacs in many respects.

Luajit in Neovim is the fastest dynamic language available, but it's a product of presumably one man Mike Pall. Some users doubt it's a real name or even one person. Luajit was developed in the 2000s and is now in a maintenance mode.
For Neovim core devs Luajit is a black-box and always will be.

Interpreters are debuggable. Emacs is the best example, absolutely everything is introspectable.
Statically typed interpreted languages are fast.

Vim9script was thoughtful and strategically right decision going against the current of situational fixes approach.

There are perfect Vim plugins that are sometimes overlooked by Vim users.
https://github.com/jlanzarotta/bufexplorer . :ToggleBufExplorer command assigned to any keymap.
https://github.com/justinmk/vim-dirvish Ergonomic directories browser.
Both plugins are simple but can impress Emacs users, how it can be done.