

VsVim - mmavnn
http://visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-46ca-8fe1-0e90e3f79329

======
johnfn
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.

~~~
dkarl
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.

~~~
tikhonj
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).

~~~
dkarl
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.

~~~
tikhonj
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.

~~~
dkarl
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.

------
Stasyan
I use this plugin everyday.

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.

~~~
palish
That is absolutely horrible. There's no reason to subject yourself to that.
Use this instead: <http://www.viemu.com/>

I've been a happy ViEmu customer for... Hmm... Three years? Maybe a little
longer. Anyway, it's just perfect.

~~~
lincolnq
Seconded. ViEmu is better. Use that instead. It's easily worth the $99.

~~~
spwmoni
Thirded.

------
scott_to_s
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).

Thoroughly recommended!

------
paul-woolcock
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.

~~~
mmavnn
It does actually support a limited .vimrc - depends a bit what types of custom
bindings you want.

------
jta
Anyone tried this and can give some insight in comparison with ViEmu from
<http://www.viemu.com/> ?

~~~
bmj
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).

~~~
jaredpar
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

[https://github.com/downloads/jaredpar/VsVim/VsVim-1.2-Beta2....](https://github.com/downloads/jaredpar/VsVim/VsVim-1.2-Beta2.zip)

As for crashes I'd love to hear about any you found. Feel free to send me
email (hacker news alias at microsoft.com) or post an issue on github.

<https://github.com/jaredpar/VsVim/issues>

------
eddieplan9
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.

------
germano
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-...](http://visualstudiogallery.msdn.microsoft.com/09dc58c4-6f47-413a-9176-742be7463f92)

~~~
jugglingnutcase
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.

------
smhinsey
It looks like a non-trivial portion of this is F#, so if you're interested in
that, it might be worth poking around the github repo.

~~~
tkellogg
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.

~~~
jaredpar
Yeah F# is a bit of a hurdle for contributors. In retrospect if I'd known I'd
stick with the project this long I probably would've chosen C#.

<https://github.com/jaredpar/VsVim/wiki/FAQ#wiki-language>

------
jugglingnutcase
If anyone is interested, i have a solarized color set fork for VsVim:
[https://github.com/jugglingnutcase/visualstudio-colors-
solar...](https://github.com/jugglingnutcase/visualstudio-colors-solarized)

i recently screwed up the breakpoints though... now they're pink.

------
jcfrei
there was a similiar plugin for eclipse around, called eclim.

~~~
ch0wn
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].

[0] <http://vrapper.sourceforge.net/home/>

[1] <http://www.viplugin.com/viplugin/>

[2] <http://sourceforge.net/projects/vimplugin/>

~~~
jcfrei
check their page; what I meant specifically was the ability to run vim inside
of eclipse.

~~~
spwmoni
"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?

