This seems to be a part of a nascent trend in IDEs. There's vrapper and eclim for eclipse, Vintage for Sublime Text, and now this as well.
I've seen a lot of arguments about how people don't use IDEs because vim/emacs are better, and I always felt they were misguided. I see the feature sets of vim/emacs and your common IDE as nearly disjoint sets, and I couldn't be happier to see the good parts of the two editors being joined with the power of the IDE.
IDEs are terrible text editors. Text editors are terrible IDEs. I can't wait until people figure out how to graft good text editors and good IDEs together.
One way to do that is to provide IDE functionality as an external service to the text editor. There's a Scala editing package for Emacs called Ensime that uses the Scala presentation compiler, a service that runs in the background. Every time Ensime is asked to colorize code, provide code completion, or jump to the definition of a symbol, it asks the presentation compiler, which gives it the right answers. No half-assed guessing; it actually runs the relevant compiler passes and provides correct information.
Another way to do it might be to embed a real text editor (not just a crappy emulation mode) into an IDE somehow. I think that's what I would prefer. Emulation modes in IDEs will always be playing catch-up, and power users of a Emacs or vim shouldn't have to maintain a mental catalog of which features have been emulated and which haven't. I don't know how it would work, though, and I don't know of anyone working on it.
To follow up on my earlier comment, the KDE platform includes a component model called KParts that, to use modern lingo, is used to perform various "application mashups", including embedding the Kate editor (comparable to TextMate/BBEdit or UltraEdit/Notepad+, including powerful plugin and scripting APIs) into KDevelop while preserving all of its functionality. KParts allow developers to control how the merguing of things like action and shortcut collections, menus, toolbars etc. is done.
I don't know about other text editors, but Emacs is actually a pretty good IDE for all the languages I use (JavaScript, Haskell, Scheme and a bit of Python). It's not very good for Java, but it is apparently solid for Scala and supports C/C++ fairly well with CEDET, although I haven't tried that.
So the external service approach works well (Haskell, Python and Scala) as does a native Emacs approach (lisp, CEDET, JavaScript). Either way though, Emacs can make a killer IDE without giving up its text editing prowess or other assorted magic (TRAMP, shell-mode...etc).
The things I miss in Emacs compared to IntelliJ, which I use every day for Scala, are find uses, jump to definition, rename symbol (text search and replace in Emacs is usually almost as good as IntelliJ's refactoring tool, but when you do it a dozen times a day, it adds up,) convenient handling of the SBT window and the run/debug window, and git integration (mostly I like looking at filenames and seeing by their color what their git status is.) Having a great editor isn't worth giving any of those features up.
I could probably get all of those features in emacs if I got everything set up correctly, but it's a lot of work. The main difficulty I ran into with Scala was generating an Ensime config. The first time I tried it, it blew up for unknown reasons. A few months later, it didn't work because my SBT project used subprojects. Now there's an SBT plugin that generates the Ensime config, so I'll give it another try someday. I'm very encouraged by Ensime's approach of integrating with and relying on the same tools as the rest of the Scala community (SBT and the presentation compiler.) It gives me hope that it won't be constantly two steps behind like it would be if it tried to reimplement everything from scratch.
However, it's definitely a problem for me if Emacs still can't handle Java well. Most of the third-party libraries I use are written in Java, so I do spend time reading and navigating through Java code. I tried setting up JDEE once and almost suffocated in yak hair trying to get basic features to work. (Granted, that was over five years ago, but still, it was much worse than advertised.)
And you know, when it comes right down to it, I really want an IDE. The whole thing. IntelliJ and Eclipse seem like bloated monstrosities sometimes, but dammit, so much of that stuff is handy when you're working on a complicated codebase. Plus they really know how to make use of my huge monitor. Using that much space usefully with Emacs and terminals is tough. I had speedbar installed for a while, but speedbar felt like IntelliJ's text editor: a half-hearted imitation of a real feature. Actually, I coded C++ in emacs for seven years and never liked using speedbar, CEDET, or even etags. They all seemed like a lot of hassle, and in every case I found that I preferred to just use Emacs as a text editor. All the Emacs-fu I learned in seven years of C++ development applies just as well to ordinary text as it does to C++ code.
Yeah, you could get most (maybe all, I don't use Scala, so I don't know) of those features. I guess we just disagree on whether a somewhat steep one-time cost is worth it.
I also recognize that it is horrible for serious Java development. I found it fine for browsing through random (usually undocumented :p) libraries, but when I had to use Java myself it was horrible. I ended up doing a bunch of things in Eclipse. Ultimately I solved the problem by not using Java :) Not a viable solution for everybody, but I think it beats the alternatives. (Unfortunately, Emacs's support for Java has gotten worse over the years, unless I missed something when trying to set it up in the past.)
My experience with IDEs and screen space has actually been the opposite: Emacs expands to fill all available space while IDEs tend to be much less efficient. I have all the UI frills on Emacs turned off (file bar, menu bar, scroll bars, flanges...), run it full screen on a 1920x1080 monitor and still don't always have enough space for everything I want. Of course, I tend to have one or two files, one or two shells, a dired buffer and maybe even Jabber or IRC open at one time, so it's doing more than an IDE would.
Additionally, in my experience, it's the IDEs that lack the features I want. I am basically addicted to TRAMP: I have maybe 10 remote buffers to three different servers open right now. However, the thing I miss most is elisp: I am able to add features I want really quickly. When I'm missing a nontrivial command (say, open a shell in the current directory, set its prompt and name the buffer) it literally takes minutes for me to add it. Little things like C-u Space (which lets me go to the last place I've marked) and undo-in-region are also extremely awesome.
As far as things like the Speedbar go, I just don't use it: I see no advantage to having something like that, and I basically never use the mouse anyhow. I do use tags, and they are useful--didn't you say you liked jump to definition?
I think the main difference is in languages: I primarily use Haskell, JavaScript and Python with a smattering of lisp, Perl, LaTeX and bash. In the near past I also used Gosu (before the IDE plugins worked, if they do now) and C. Emacs is great for all these languages on top of being both a brilliant editor and great window manager/os (I seem to do everything but browse the internet from Emacs these days).
It really is horrible for Java though. And Java is particularly horrible without an IDE. Still, for quite a lot of other languages, it really is like an IDE. I guess not very many Java hackers use Emacs and not very many Emacs hackers use Java.
etags didn't help me much with the C++ code I worked on. It took me to the right place a lot of the time, but between the macro-heavy C code I inherited and the modern C++ code I was writing, it wasn't reliable enough for me to put up with.
The same thing was true of all the C++ IDEs I tried, though. No tool in the world except gcc could handle our C++ code. We even had a file that defeated Emacs. It was a huge file that used a logging macro that included a leading parenthesis but no closing parenthesis, so there were hundreds of lines like this:
LOG "A log message", logFile);
Result: Emacs locked up when you opened the file, presumably while trying to colorize the syntax.
Whenever language support is that poor, text editors and other Unix text-munging tools win hands-down. All I had to do in Emacs was disable the cc mode hooks and fix up the file using query-replace-regexp. IntelliJ has the equivalent of query-replace-regexp, but it's clunky and bothersome enough that I went from using it as a daily tool in Emacs to almost never using it in IntelliJ. That's pretty much what happened to me with Emacs' IDE features, so it's kind of a symmetrical situation.
You can already setup Eclipse to be an external service to vim using eclim. I tried that for a while and it works, but then I realized that all the disadvantages of using a heavy IDE (project setup, project switching, startup/shutdown, inconsistent experience across languages and machines) were weighing me down too much.
I'm still having trouble seeing the value of an IDE.
When programming, all I'm doing is editing text and occasionally running an external program. what does an IDE have that makes it so valuable?
(Honest question! I've used IDEs in the past - MSVC, Eclipse, NetBeans, Anjuta, Code::Blocks, and several others - and found that the generally poor editors made it more difficult to program.)
I've been told by IDE users that a large part of why they use IDEs is just how much work it can do for you without you having to think about it. Need to change a class name that gets referenced hundreds of places throughout a project? Project-wide search and replace! Can't figure out what the string of 4 integer parameters to a function are? Just hover over it with a mouse and the IDE will tell you! Some IDEs even go so far as to create code for you using templates. And then there's always interactive debugging.
But, all this wonder comes with a price. For me, the key reasons I prefer vim to any ide out there is:
1) speed. compared to vim + bash, every ide is slow.
2) code portability. I work with lots of different languages on a daily basis and having to switch from Eclipse (java) to Monodevelop (C#) to whatever the http/css/php du jour is these days.
3) IDE maintenance. No matter what you use, ides have a ton of setup overhead just for the specifics of the project you're working on, let alone if you want to customize the environment.
4) fragility. Vim + bash rarely breaks or leaves me unable to work on a project. I have been left high and dry by IDEs multiple times. All it takes is a coworker checking in personal changes to a team-wide project file. Then you're left in a broken state, figuring out what went wrong.
so, there are some pros and cons. Everybody's style is different and there are real advantages to both approaches.
For one, they provide a way to stay immersed in all aspects of your project continually while switching around between tasks (seeing your files/class tree + code + warnings/errors + status simultaneously on one screen). Even if you're savvy enough to achieve some of this through a careful terminal splitting/tiling setup, you're just halfway-implementing a graphical interface.
Like most GUIs, you're also provided with organized menu-based access to tools and features you might otherwise have to spend time remembering or learning how to do from a terminal.
Finally, IDE-centric features like in-editor static analysis / error highlighting can come in handy from time to time (Oops! Forgot a paren. Glad I didn't have to waste 15 seconds attempting to build, reading/understanding the error output, and coming back to this file/line).
(I agree that a lot of IDEs I've tried such as MSVC and Eclipse can be burdensome to use. I like using Geany, since it's foremost an editor, with useful panes and functionality added in.)
Emacs also lets you stay immersed in all aspects of your project at once. However, unlike a GUI, using different panes in Emacs is uniform: the commands you use to get around the file/tree view are the same commands you use to get around your code are the same commands you use to get around your compiler output.
Emacs also provides some really nice technology for finding commands including ido-mode and C-h m (which lists commands for the current mode and is incredibly useful). However, here the real magic is that getting around a help buffer is again the same as navigating code--you can use the same command to search and the same commands to move around.
Emacs also has a nice system for integrating arbitrary output from an external process into your code, letting you have error highlighting and static analysis for arbitrary languages. On top of this, it has several really nice modes like js-2 and SLIME that create an even more compelling experience for certain languages.
On top of this, Emacs has a bunch of really nice features like TRAMP which lets you visit arbitrary remote files and even open remote shells trivially. On top of this, it is much easier to extend than any IDE or even any other editor I have ever seen.
So really, Emacs can provide everything you want, it can provide it in a much more consistent UI and it is infinitely configurable.
Well, with the exception of a class tree (which I've had trouble using in the past), those are all the reasons I just use a text editor. So, I guess I still don't understand.
You see, I have file/project trees, warning/error buffers, build status and shells (among other things) in Vim and Emacs with keyboard-driven access to all the tools I use, without having to hunt through a twisty passage of menus, all alike.
Even static analysis and error highlighting is available (even for C++ with vim-clang-complete, for example).
So I guess what I don't understand is why there is a need for all of this to be "integrated" in a WIMP-style GUI.
* Auto-complete (that actually works based on the syntax tree of your entire project, not just text matching)
* Refactoring tools that can not be done by an editor that does not also understand the language. (like block select -> "Extract Method" or "Implement Interface")
* "Go to definition", which can take you to the definition of a method, property or field, that always works, even with the most convoluted syntax.
* Debugger and breakpoints integrated into the environment
* Expression-level type inference, or the ability for the IDE to tell you the type of an expression, and examine that types' definition in all cases.
* Basically any manipulation of the files that requires more understanding of the source files than text-based operations.
I find them most valuable in a larger codebase. The project I work on at Google is millions of lines of Java. I'm an Emacs user by preference, but a lot of my job isn't writing code, it's discovering and using the existing abstractions. For that part of my job, Eclipse serves my needs a lot better.
Even better, there are vim keybinding plugins for just about everything - Chrome, Chromium, Firefox, Opera (if it's updated now, not sure). Even Emacs (vimpulse). Combined with IDE plugins like eclim you can set up a single unified key interface to almost everything you do on a computer.
That's largely my thought. I love Vim, and it's occasionally frustrating when VsVim doesn't cover a corner case; but the functionality of VS with ReSharper means that for .net code I'll put up with it.
Wow, vrapper is what I've always wanted. Thanks for posting this. Its always amazing to me when some part of someones comment really changes my daily development. This is one of those times!
It's got some serious bugs that make my heart stop.
The biggest one is Undo. Looks like the plugin keeps it's own list of modifications that were performed. So when sometimes I press "u" to undo the latest change - Visual Studio gets suspended for a minute or two, and all my changes that I did since I opened Visual Studio (could be a day or a week) are pretty much gone. The work around is to close the file without saving.
Hopefully stuff like this will get fixed now that the project is accepting contributions from other developers. There was a point where his employment agreement prevented such from happening.
It's great to hear that VsVim is finally accepting contributions from outside of Microsoft.
During my internship at Microsoft last summer, there was one day where the interns in STB got into groups of about 5 and presented on topics of strategic importance to Microsoft. My group presented on how Microsoft could better embrace open source, and during my part of the presentation I focused heavily on how many of Microsoft's "OSS" projects don't accept outside contributions.
I used VsVim to showcase how Microsoft was doing open source wrong. It was a great example, because Jared Parsons seemed to be doing everything he could to be a good OSS citizen and reach out to those who typically use an OSS stack (by putting his project on github instead of codeplex for example), but he had to turn down contributors outside of Microsoft as a matter of policy. I also didn't suspect that Microsoft would be repurposing a Vim emulator plugin written in F# for any of its closed source projects, so it didn't make sense to stop outsiders from contributing out of fear of losing complete ownership of the codebase.
Several high-level execs in STB including Satya Nadella were there, so I would like to believe that my presentation played some small part in Microsoft now allowing outside contributions to VsVim. A discussion of VsVim's contribution policy ate up a lot of the question and answer session after my group's presentation, so it was pretty clear that I wasn't the only there who thought it was messed up.
What version of VsVim are you using? There was a bug with this exact behavior in 1.1 (and possibly 1.1.1). I got it fixed for the 1.2 release which is the current version in the Visual Studio gallery.
My development work is a polyglot split across Linux, Mac and Windows/.NET projects. I also use both Vim and Vim keyboard bindings (in other editors) on Unix.
Whilst I prefer *nix, when I have to use Visual Studio, I use the VsVim plugin, and it's a real pleasure to be able to seamlessly move between platforms and development environments, IDEs and text editors in this way.
Not only do I love VsVim, but it significantly reduces the friction of using Visual Studio, and even adds some enjoyment to coding on that platform. VsVim is F# under the hood too (which shouldn't matter to the user, but it _is_ kinda cool).
Putting the standard key bindings for vi is one thing, but without being able to customize it like vim, it's almost worthless to me. The custom bindings I have set are there to do common operations, and they become an integral part of my vim.
I use this daily in VS2010, and have used ViEmu in previous VS versions.
Generally, I like it, but it can be a bit sluggish at times. The only plugin I have running is JSLint, so I suspect it's VSVim causing the problems (though it only generally bogs down when I leave VS2010 for a bit). The keybindings work as one would expect. As I mentioned in a different thread, I wish it could break out of the tabbed window convention of VS and use buffers.
ViEmu did feel a bit faster (and was less prone to crashing).
What version are you using? Prior to 1.2 there was a nasty perf bug with :hlsearch that caused it to be sluggish with 1) very large files or 2) a good number of files opened. The bug is mostly fixed in 1.2 but there are still a couple of corner cases. Those are addressed in 1.3 which will be released sometime next week. A beta drop is available here
I can chime in as I just purchased ViEmu. It's really wonderful to have all the Vim bindings present in studio (and the rest of Office!). I haven't noticed any speed issues and I haven't noticed bugs (yet), but I've only been using now daily for two weeks and I haven't installed any plugins for it.
This is very off-topic, but I am turned off by the URL. Is Microsoft obsessed with UUID? First, they have you use UUID to reference COM components. And now in URL? Next you will see them ask their own employees to use UUID as email addresses.
If there's anyone out there comfortable in both the way of vi and the way of Emacs, does this feel better than the Emacs emulation [1]? I'd love to be able to work with text more efficiently in Visual Studio, but the Emacs emulation feels only half way there.
[1] http://visualstudiogallery.msdn.microsoft.com/09dc58c4-6f47-...
i used to use the emacs emulation and i agree with you, it only felt halfway. Also, Jared seems way more responsive than the emacs people. i filed a few bug reports and saw few status updates or general updates. After feeling frustrated with that and the half-baked feel i switched to Vim and found VsVim. i've been really happy and havent looked back.
Funny, I actually cloned this repo last night to contribute. I really want to contribute because it's so useful and @jaredpar seems to be doing a shit ton of work all by himself. But the whole F# part is going to be a hurdle.
Isn't Eclim the other way around? I thought it would include features from Eclipse in Vim rather than bringing key Vim keybindings to Eclipse. There are several plugins for the latter though, like Vrapper[0] or ViPlugin[1]. There were also attempts to integrate a whole native Vim instance into eclipse[2].
"The primary goal of eclim is to bring Eclipse functionality to the Vim editor."
Maybe you're talking about vimplugin, which eclim uses a fork of to embed gvim in eclipse?
I've seen a lot of arguments about how people don't use IDEs because vim/emacs are better, and I always felt they were misguided. I see the feature sets of vim/emacs and your common IDE as nearly disjoint sets, and I couldn't be happier to see the good parts of the two editors being joined with the power of the IDE.