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)

code of conduct - report abuse