So true - I'm not sure what I expected.
It always comes down to the fact that:
a) There is no intelligent auto-complete (not compared to an real IDE)
b) Background tasks of compiling/testing will block the UI. With scala especially, this is an issue.
c) No comparable refactoring capability.
I once had high hopes that eclim would be the answer, but I think it's just the wrong tool for the job. Let's not pretend vim can be something it was never designed for.
Neovim however might help to solve this problems, but when that will see the light of day, it seems to be hard to find out.
Feels like I'm spamming every comment within this article, but this is exactly what Ensime is for. I hope that Vimside (http://www.vim.org/scripts/script.php?script_id=4298) up to date which addresses most of the above.
I don't think it would be too hard - mainly the server startup has been tweaked so you dont embed Ensime.
Neovim is also interesting, I understand they have a much nicer plugin architecture as well.
> Neovim however might help to solve this problems, but when that will see the light of day, it seems to be hard to find out.
Neovim is working quite well already. I fully switched from vim to nvim months ago without any issues. Plugins are still written for vim though, so I don't think many take advantage of neovim-specific features yet. It does have a full terminal already though, which is pretty awesome.
edit: Oh, I'm guessing you're referring to the promises of embedding neovim inside IDEs. I'm looking forward to that too!
YouCompleteMe (https://valloric.github.io/YouCompleteMe/) is a code completion engine built on libclang and works quite well. If you happen to use cmake for your projects and tell it to emit the build database file (CMAKE_EXPORT_COMPILE_COMMANDS), YCM can use it. As with anything in vim, you don't get this for free - the setup is non-trivial.
install boat-load of addons to try and replicate the IDEs they're decrying
The attraction is that vim is usually far more customizable and supports modeful editing (yes, there is IdeaVim, but it is quite a leaky abstraction). However, customizability comes with a price: it takes a while to set up.
The same holds for other applications. E.g. Mail.app is user-friendly, but there is little you can change in terms of shortcuts, behavior, etc. OTOH mutt takes a lot more time to set up, but you do nearly anything you want (including setting up GMail shortcuts and behavior).
3) still somehow recommend it even though it appears to be less efficient in the use case provided
That's why I also use IDEs. E.g. Go is really well-supported in vim, with completion, refactoring, etc. For Java, OTOH, vim cannot even come close to IntelliJ and others. So, I use an IDE.
I think vim-go has a really nice balance here. Part of the strength comes from the excellent tooling the Go community created. Each tool is orthogonal to each other and they are pluggable and reusable. So vim-go for example uses these tools to create wrappers around it and blend it like it's a part of Vim itself. It's not a IDE of course, however it feels like that.
I think the most important thing here is providing a orthogonal tools and well defined boundaries between them (which the Go tools have achieved already). Once that is established, more greater and better tools can be created upon on it.
I look for other language plugins from time to time and each time I see the same thing. The language which the plugin is build on itself doesn't have the sense of "orthogonality". So it makes it difficult to create plugin and support it. Once the underlying language and the community get the sense for it, the tool(in our case the Vim plugin and ecosystem) will improve itself too.
Re 3: That's also confusing me a little. People start to believe in the power of Vim, go a path that doesn't show them the power and then still believe in the power. I guess, brains don't like to have put so much energy in something, so they must conclude it was a good move no matter what.
You can take it as evidence that making things objective is difficult. That is, the point is that despite all of this effort, the author recommends it. There is something to be said for those decisions.
For myself, I have taken to using less and less of what modern IDEs do. There is value in using a tool so that you don't have to internalize details of a project. However, the win from having internalized it is a very good feeling. To the point that when you find you are navigating abstractions, the answer is not a new or better abstraction, but to get rid of it. Will you have to understand more? Certainly. But this is not an unattainable goal.
1) install boat-load of addons to try and replicate the IDEs they're decrying
2) make vague and short statements on "the benefits" usually near an entire paragraph about the drawbacks
3) still somehow recommend it even though it appears to be less efficient in the use case provided