We did - hopefully you enjoyed it. We are talking with the maintainers of the sublime plugin to bring it into the ensime org and I'm trying to a vaguely working version out in the next few days.
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.
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.
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.
> I think it’s more of a philosophical difference rather than technological.
This is where the argument lives but a lot of people don't necessarily understand this kind of decision making.
I like IDEs and I love command line. If I have a choice I will go CLI 90% of the time. Why? I feel most comfortable with the command line and I think it looks good, runs good and allows a ton of customization.
Using R for analytics I use the IDE RStudio
Need a REPL I use Project Juypter (IPython kernel agnostic)
I also code Scala for a living and the Scala experience in IntelliJ is pretty far ahead of anything else. It feels very close to being just as polished as using Java in IntelliJ.
Help with implicit conversions is ultimately the killer feature for IDEs in Scala. The language itself is littered with them, (take a look at StringOps and StringLike), and type classes are used all over many libraries.
The simpler the language, the easier it us to use it well without an IDE. I love Scala, but I'd never call it simple.
Couldn't agree my more. I'm a big fan of Sublime, but when I work on big Scala projects at work, I'd be MUCH less productive without IDEA.
The only significant wart for me is the mismatch between SBT and IDEA projects. IDEA is stricter, there are valid SBT project structures that IDEA hates. Can crop up if you're working on other people's projects, started with Eclipse or a text editor. Other than that, IDEA is phenomenal for Scala development.
I'm really hoping that someone uses our recent work on Ensime to bring vimside back to life. Hopefully provides a lot of the 'missing' features that vim (semantic/type info), accurate completion etc. But its going to require a Vim expert to step up and fix the integration.
Finally I settled to live with scale ide(eclipse) with vrapper for limited vim functionality. All the plugin setting and feels extra waste of time and work.
Did not face any issue with speed, especially in the latest IDEA version. I run it on ssd with i7. There some minor issues like :w is useless in ide as it saves it anyway and recording does not work for me. But the benefits of ide + functional vim greatly outweighs just using vim.
30 comments
[ 2.2 ms ] story [ 84.7 ms ] thread1) 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
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.
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 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!
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.
[1]: https://github.com/fatih/vim-go
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.
http://support.wasdkeyboards.com/customer/portal/articles/19...
This is where the argument lives but a lot of people don't necessarily understand this kind of decision making.
I like IDEs and I love command line. If I have a choice I will go CLI 90% of the time. Why? I feel most comfortable with the command line and I think it looks good, runs good and allows a ton of customization.
Using R for analytics I use the IDE RStudio
Need a REPL I use Project Juypter (IPython kernel agnostic)
Just about everything else I use VIM.
- The ability to safely rename identifiers.
- The confidence that the "Find usages" tool gives on a large code base (search just doesn't cut it).
- Immediate, contextual syntax error information.
- Excellent auto-complete.
- Quickly navigate to declaration.
- Syntax-aware indentation.
I usually have an sbt session open that is either running unit tests or running a Play Framework server (with auto-reload).
The simpler the language, the easier it us to use it well without an IDE. I love Scala, but I'd never call it simple.
The only significant wart for me is the mismatch between SBT and IDEA projects. IDEA is stricter, there are valid SBT project structures that IDEA hates. Can crop up if you're working on other people's projects, started with Eclipse or a text editor. Other than that, IDEA is phenomenal for Scala development.
Something that I find useful is proper ctags extraction for Scala, so here it is: https://github.com/luben/sctags
I hope it may be useful for other people developing in Scala in Vim.
From eclipse I get - intelligent auto complete - refactoring - code search
From vim I get - remote work through mosh + tmux - preferred editor semantics
Eclim has scala support, but I don't know how full featured it is.
You can use Vim inside your IDE as your text editor of choice. Using Vim as a hacked together IDE is a misuse.