Vim Is The Perfect IDE

Allan MacGregor on June 10, 2018

This article was originally published in HackerNoon Over the years I've jumped back and forth between many code editors, IDEs and tools; but it se... [Read Full]
markdown guide where is the dislike button? :/

  1. VIM is not an IDE, just an editor that helps you write faster

  2. After you install 30 plugins and spend years of learning it you can come close to an IDE, but you lost a lot of time, for nothing.

  3. The length of the post and the config file is working against you, is proof that is not easy to work with, and still not doing a proper job

If you would use an IDE in a proper manner (See Visual Studio or intelliJ) you will realize that your productivity is not about writing text (what Vim excels at), is at making your code work in the real world. Is more about development and less about being a type writer.

If you write books, articles or pseudocode Vim is the best tool I agree, but
the devs usually need to do DB queries, work with env tools, debug, see static analyzers warning, deploy dockers, run automatic tests, do merges, do huge refactoring that touches many files, find the "blame" on a bug, and so on (without writing or remember CLI commands or wasting time to setup the IDE).

Just saying, as a "director" you should appreciate productivity and do not make "feels like home" decisions for work projects. Do not confuse "what I like to do" with "what I have to do, as a professional".

By not using the proper tool, that gives you the fastest and most productivity you are wasting your employers money, so you are not being professional, you are just selfish.



VIM is a tool, every developer is entitled to its opinion and preference, VIM might not be the right fit for all stacks or all applications but I have successfully use it to work as you mention for writing, python development, elixir/erlang development.

IntelliJ is great and I use it for other kinds of development (ionic for example); I find the knee jerk reaction to the size of configuration file a bit risible, the configuration file as shared has support for several languages, stacks and some of my personal customizations.

Finally, I find that the ad hominem attack on the last part of your reply actually subtracts from what was actually some valid points on your argument.


I just wanted to raise awareness on "VIM priests" that spread their false gossips around, I probably sound more passive-aggressive then it should.

You just "forget" to mention that it is a personal preference, and state that "Vim is the perfect IDE" (for me?!), knowing in fact that is not even an IDE and not perfect. You "forget" to mention that you spent maybe years of being prolific, where in IDE's most of the things "just works".

VIM is great when you have many small scripts/projects, or you alter big projects with minimal invasion, edit big files, or you are a sys admin, or ...(insert here a lot of stuff you didn't mention), but ....

It is "a common trap" that I've seen are with web dev juniors, they usually:

  • find a post like this
  • decide to try VIM and like it
  • they are getting very good at coding (typing fast,and moving around the document)
  • they have the false productivity feeling (the amount of code != solving more business problems)
  • they advance to bigger projects (as in scope and LOC count), and hit some walls. Then invest more and more time in their VIM skills and configs, and in the end being less productive.

This combined with the fact that people hate change, leads to bigger problems once the developer gets involved in bigger and more complex projects.

I just want to make things clear for the juniors and next generation of developers to make a big difference between "personal preferences" and "best tool for the job", and posts like this doesn't help at all.

Please keep in mind that everything you've said so far is anecdotal. Others, such as me, may have different experiences.

I tend to agree with BG. Tooling becomes vastly important when working with larger and more complex codebases. The kind of code analysis provided by actual IDEs simply cannot be replicated in Vim no matter how it's customized.

Vim is great, but Vim is ultimately just a powerful text editor. BG is correct in that the anti-IDE stance is alluring for junior devs, providing false machismo in the absence of experience and well-honed skills.

We really need to change the way we talk about Vim. Here are my suggestions:

  • Stop comparing it to emacs. They are vastly different things.
  • Let's distinguish Vim "the concept" from Vim "the application."
  • What's important here is Vim, the concept

Vim, conceptually, is mode-based text editing with consistent, highly optimized keybindings. The beautiful thing about vim-as-a-concept is that it's available in some form or fashion in nearly every IDE and text editor.

"vim-as-a-concept is that it's available in some form or fashion in nearly every IDE and text editor." ... and browser.

In my line of work, I've seen little to no benefit with static analysis. I am working on a highly dynamic codebase. Sure, if your language is static its great, but I really don't see this as being a reason for not using VIM. I've actually seen VIM autocompletion be more accurate than IDE's (for newer languages such as Rust).

I am very curious in what languages/line of work there are no benefits for static analysis, can you give some examples?

wow ok, your team is great then! I was part of teams that didn't used but we ended up regretting.

I usually saw linters solving a lot of (very small) problems in large teams and projects, like (forces a coding standard, find small bugs like forgetting to type a var or forgetting a switch default, fewer git merges/conflicts) which leads to a better codebase in general (if you enforce the rules at commit/build).

As a sidenote linters are builtin in most IDEs so maybe you use them already, but only at a basic level.

We use eslint (for the older projects, a combination of jshint and jscs). The plugin I use for vim (ale) works with pretty much any kind of linter I've encountered.

This isn't the sort of static analysis I'd expect from and IDE though, this is what I'd expect from any kind of programmers editor (vscode, sublime, etc). What I meant by static analysis is the ability to goto definition, display documentation, refactor, etc. This is the sort of stuff which doesn't work consistently enough with our codebase to even bother trying.

"The beautiful thing about vim-as-a-concept is that it's available in some form or fashion in nearly every IDE and text editor."

Personally I'm yet to find any implementations that replicates vim entirely. In every single one I tried I stumbled at something that just didn't work (often f/F/t/T, or ci( are missing, but even in the best "vim-mode" I've been working with so far there was something missing).

"What I meant by static analysis is the ability to goto definition, display documentation, refactor, etc."

You can have all that in vim. Look at YouCompleteMe.

PS. I'm not trying to say vim is for everyone - it has a very steep learning curve, so unless you don't have time to spend learning it, stick to IDE. But for those who did learn how to use vim any IDE gets obsolete.

PS2. I'm working with pretty much bare vim - at the minimal I use only YouCompleteMe, language-specific omnicomplete if needed, vim-gitgutter, syntastic, vim-autotag, and vim-polyglot. And still the ability to move through the code fast exceeds what I'm able to do in other IDE. I do have some shell command trickery set up in my .vimrc though (nnoremap to various !find [...] and !grep [...] shell commands)


Ha, these kinds of comments always baffle me...

Your comment can be summarized as:

Your personal preference is wrong... You are not more productive with your favorite tools.

It's like telling someone "No, you shouldn't like chocolate", or "Your favorite movie is wrong".


Chocolate and movies are indeed a matter of taste, but productivity is not (also note that 'feeling productive' and 'being productive' are two different things).

Of course, these kind of discussions tend to spiral into the following, myself included :-)

Duty Calls


That is the problem, he didn't specified it is a personal preference, he said it as an absolute truth and other people can make wrong decisions.


Linux, the whole environment, is your IDE. Vim is just one part of it.


B.G. ..... My subjective opinion: you are bore and hysterical. It is a fact. And all about what you find fault with the author of the article applies to your claims. All this is subjective, even your praised productivity.

I apologize for my english - google translate.

"Stay hungry ..stay foolish.". Steve Jobs.


Nope sorry, productivity can be measured, and the time you invested to reach that level.
Also my claims can be easily verified after one week of Vim.


the devs usually need to do DB queries, work with env tools, debug, see static analyzers warning, deploy dockers, run automatic tests, do merges, do huge refactoring that touches many files, find the "blame" on a bug, and so on (without writing or remember CLI commands or wasting time to setup the IDE).

I can do pretty much all of that in Vim with only a handful of plugins and little configuration. Also of note I've been in the biziness for roughly 7 years and have never had to deploy a container. 🤷🏼‍♂️ YMMV


This, so much. I downloaded VSCode, used a clean GUI to install a few plugins, and I was developing nodeJS in minutes. That vimrc convinced me to never use the editor for anything serious.


where is the dislike button?

VIM is awsome, but not for everybody


vim exit

I am actually using Vim, my point is that title of the post should be "Vim is the perfect IDE ... for me".


I'd also like a dislike button. VIM is like all kids in the 80s who knew how to solve the Rubik's cube puzzle decided to make and IDE version. An over complicated, hard to figure out editor. Which they can feel superior in using knowing that only they know how to use it.


Nowadays I'm a Visual Studio Code user, but both Vim (:help) and Emacs (C-h t) have excellent built-in help systems, so they aren't really that hard to learn. You're wrong about the 80s kids though ;-) – the first versions of both Emacs and vi were released in 1976 (and Vim showed up in 1991) when their interfaces were far from being esoteric but actually rather sophisticated.


I was more referring to descriptions of the overlords than the timeline itself. Rubik's cube was the first thing to come to mind and I think that was the 80s.

I understand, I was just trying to point out that not everyone who uses either of them thinks of them as something special and that they are actually fairly approachable. For quite a while Emacs/Vim were the best we had and it's hard to switch tools sometimes. That said, after quite a few years of heavy Emacs usage I switched to VS Code last year and am really happy so far, mostly because its core feature set aligns well with the work I'm doing everyday.


I love vim. I started learning java on a Chromebook, which Eclipse proved too much for and wound up on Codenvy. From there I messed with IntelliJ and Eclipse Photon but I really didn't like either. Especially Eclipse photon plugins suck, the ui feels laggy, there are tiny mostly inconsequential bug that are just annoying enough to trigger my OCD. I get the benefits on a larger code base but vim is something that can be fine tuned. Sure it's more work, but I can be sure vim (neovim) will work smoothly and exactly how I want. The LanguageClient plugin I run is way more consistent than the vscode redhat plugin and they share a! I'm an obsessive tinker and vim fulfills both for me!


What do you care what another developer uses? This sounds like just another Mac vs Windows vs Linux argument that is all opinions

BTW, I know of companies that use Notepad++ as their "IDE" and in my opinion it's no different than vim(or a variant like Neovim).


"BTW, I know of companies that use Notepad++ as their "IDE" and in my opinion it's no different than vim(or a variant like Neovim)."

well, the whole thing about vim is the fact you don't move your hands from home row, and the command chains are easy to remember once you're used to it. For example when you know dw and cw, and then learn f/F/t/T you already know how to combine them. and the letters have mnemonics to remember them easily. On the other hand I don't know how to, in any other IDE, for example delete everything inside curly braces, and start editing the method from scratch.

You can double click opening or closing brace in Eclipse to select the whole block. Then type to replace!

This requires using the mouse, which means moving the hands from the home row. This really slows me down. Nice to know there is such feature though.


I don't care what another developer uses. It literally does not matter, in the long run. However I like these arguments. It's always funny to see the more extreme reactions and insightful to see the discussions to these small details.

Do you know why I love these arguments? Simply because I'm not arguing with some faceless twitter avatar about why women, people of color, LGBTQ+ people are under represented (or underpaid) in STEM fields. I don't have to make some passionate argument as to why basic human decency and inclusion should apply to everyone.

You get into a having a real discussion about people's experiences and why these features matter from one person to the other. I just enjoy the debate.

You're right though, it does not matter.


I'm in the same place. It seems like one a year I go out and try out other editors or IDEs, and always find myself in vim. Well now Neovim and using deoplete. I've tried the new language server protocol, but had some prefomance issues. To answer the question below. I primarily develop Go these days so I have that deeply integrated. Delve for breakpoints, I get in line errors as well simple key bindings for extra go metalinter tooling. It does take work and your config is a living setup.


Would you mind to share your Go config for (Neo)vim?


"Vim is my default Ruby, Elixir, Python, PHP IDE" . I have noticed all these languages are dynamically typed.

You can't compare the power of intellij for statically typed languages over any text editor as sophisticated as it can be. I have noticed as well that for dynamically typed languages it's not that much of a powerful difference (there is but not as for statically typed languages) if you use a light text editor or ide.

  1. Can it show show call hierarchy?
  2. The exact types of expressions? Show method callers?
  3. Search for variable references?
  4. Search for function references?
  5. Suggest and complete function and variables types?
  6. Show compile errors as you type? In code itself (red line).
  7. Refactor correctly large codebase?
  8. Suggest to change parent variable name or.method names when refactoring child?
  9. Powerful debugger.
  10. Build in coverage markers.
  11. Git annotate blame in source code.

Much more powerful stuff which help maintain and analyze codebases and projects not written by me. Or written by me and maintained by others.


well, if you use YouCompleteMe (and some other tools for git and tests) then yes, to all these questions aside from debugging.


Hi, while I didn't use it is this sounds amazing and worth checking, but does it do show call hierarchy? I saw:

I don't know what "call hierarchy" is in context of the editor (such term wasn't used when I gave up on graphical editors), but searching the web for "call hierarchy vim" I see few different solutions. (some of these suggest me "call hierarchy" might be what I know as "find references" functionality, in which case in YCM it depends on the language)


8 Of these things are covered under LSP specs. LSP really makes these features portable to just about any editor that can implement LSP client.


I'm a vim fanboy, I really think it's a great tool but it's far from being perfect. The great thing about vim, as you demonstrated in this post is that there's an unlimited amount of customization you can do to it. With that, I can't imagine two developers having the same set of plugins and the same vimrc file. It's just so personal.

The title you've chosen is somehow provocative that's why I can see some violent reactions here. But I understand, that's not your intent.

For me the best way to learn vim is to see how others use it. And I appreciate you sharing what you got. Thanks!


I really appreciate vim but honestly there are some functionality that other editors have already configured like: you can view immediately unused code, jump to a file easily and fast, autocomplete methods and variables name.
This features can be added on vim but sometimes they are hard to configure and many times is too difficult to do it in my opinion.
But for many files I use vim for example: configuration file, markdown, readme and others.


Autocompletion of anything in open buffers is available out-the-box. Jumping to files depends on what you mean, but capital-letter marks and things like gd and gf will do that for you. Buffers match by partial and filenames autocomplete when opening them. Unused code is a much more IDE thing though, which requires actual inspection of the code rather than pattern-based syntax highlighting.


How many times are you going to repost this same article?


Too much plugins for too little benefits. I do not traverse the directory tree. I search files, I search for words in files. I use abbreviations and macros for writing code, refactoring, compiling, testing,... everything in the Vim. I don't want IDE. I like my Vim.


I'm somewhere in between you and the OP. Here's my configuration:

I've chosen to be pretty conservative with it so far but Vundle and a number of the things that can be installed with it are really good. That said, at this time I still only have nine Vundle plugins downloaded.


Not a snarky comment, I'm truly curious: How tough is to do debug tasks (set breakpoints, view/modify variables, etc)?


When it comes to debugging I'd rather go to IDE if I have the chance, even though I'm a die-hard vim user myself. But since I'm mostly working on servers the "how tough" is a non-issue for me, since my only alternative is to use command-line debugging tools (e.g. node inspect, or perl -d)


Closest thing you get to an IDE debugging support would be something like which supports PHP, Python, Ruby, Perl, Tcl and NodeJS.


Tried to set up my vim using your .vimrc file. The plugin install hangs on the jakedouglas/exuberant-ctags plugin, further examining revealed the repo on github no longer exists

Note: Fixed by removing Plugin 'jakedouglas/exuberant-ctags' line and installing package with sudo apt-get install exuberant-ctags instead (on Ubuntu 16.04)


Lots of interesting things here, hadn't had the time to thurougly look at it, but one thing right away: Maybe you don't want to post your github auth token on here.


I have been pretty happy with IDEAvim plugin for IntelliJ products. It even works with a custom vimrc. But not the plugins. For the plugin stuff I just rely on IntelliJ and it has been great.


it's the closest "vim mode" plugin to the actual vim, but even there I stumbled across some functionalities that were not implemented. But then I'm using vim for over 15 years now, I use pretty much everything it offers.


Also happily using it, but have that issue, that keybindings work inconsistently in dialogs (


Someone once said, "Linux is like a huge woman, once you get your arms around her, you'll begin to love her.", I think same example goes with vim as well, once you get to know 'her' you'll begin to like her more than any editor/ide.
You can argue that, you'll waste time learning it, well, it is always a trade off, depending on what kind of tasks you are handling, for local development , I usually use atom in vim mode, much efficient than what I used to be with 'regular' mode. well , what I find most demanding at the moment is , where I have to write program on a remote machine with only ssh access, inside another private network, there are hundreds of servers constantly require writing something or modifying, all testing environment are on remote private network, which is pretty hard to get exact duplicate on local, so we end up writing stuff directly on the development server, tried c9 and other remote ide's ,but non of them were fast and agile enough to compare with vim so far.
So unless you need it, it is fine you can always use your favorite 'super duper' IDEs , but if you want to be able to write code everywhere fast, I recommend creating a vim configuration on git, then wherever you need, just clone it, and use it, no desktop required. since we always have terminal access.

Close to <insert IDE name here> ? Probably pretty close.


At a previous job, I used VIM because it was the editor the other devs were using, and specifically there was remote pair-programming that utilized VIM. Now, I know folks love it -- the devs at the job sure did -- but I loathed every minute of coding with it.

The basic paradigm felt like it was eschewing any modernity just for its own sake, as though the peak of computing tech came into existence 40 years ago, and not even something like the newfangled mouse would be acknowledged. The idea of flipping between modes struck me -- and still does -- as ludicrous.

The two main perks of the VIM, as far as I've ever seen, are both related to speed: one being that you never need to move your hands off the keyboard, and the other being at how fast the editor lets you work. And while I can type at upwards of 90 words per minute, I don't program at that speed. Do any of you? I wonder how relevant that level of speed is to anyone.

And as far as the speed it grants you … I never really saw that. Not just from my own begrudging use, but I lost track of the amount of time I spent watching the other devs going into change something and bragging about the speed of VIM, only to spend a lot more time making whatever change than it would've taken with an IDE. Now, I can't say that all of the dev in the office weren't just totally clueless about how to use VIM, so maybe it's their fault, not the editor. But there were 6 of them, and it was consistent.

(If it's an editor you like, that's cool. I personally like Visual Studio Code, as it's a good mix of time-saving keyboard shortcuts with features using technology developed in the time since man's landed on the moon, but since this conversation is getting all testy I figured I'd jump in)


Curious to know what you all think of ( our online code editor for building APIs.

I build this handy service by merging two API's on :

Comments are welcome :)


Good enough actually :D see the error detection part in my old post


It'll pick up things like duplicate function definitions but undefined functions, not so much. That's IDE territory.


Just come back to say thank you, the article and github repo is helpful.


OMG. You surprised me with VIM > Merci beacoup


As a friend told me time ago, old tools and console commands raise the ego of developers. But finally, you must choose a tool and you should work with the tool that feels you more comfortable.


Great post(+flollow), keep up the good work ...
Good luck.


I'm constantly tweaking and looking for a better setup, however Vim always feels like home to me

You said that about using an IDE.

I hope that for some of you this post has been helpful for some, and I'm far from done with my current setup, in that sense this is very much a toy that I continue playing on a nearly daily basis

And you said that about using Vim.

So what was your problem with "constantly tweaking and looking for a better setup" in an IDE?


Why do you think I have a problem with an IDE? Just because because I have preference for VIM and use it as my main editor that doesn't mean that I hate, dislike or not use any other IDEs.

For example for mobile application development I do use an IDE xcode/IntelliJ.

A lot of the comments I've seen come from this post are much on the vein of "this person uses and likes different tools than I do, bring the pitchforks and kill!!!"

Seriously, if you don't like VIM and you prefer to use an IDE, good for you thats your choice. Use the tools that work best for you.

code of conduct - report abuse