Thursday, March 12. 2009

Why Vim Plugins for IDEs Fail

I'm an unabashed Vim user. It has been my primary editor for over seven years now, when I switched to it to make it easier to edit files over SSH. At the time, I made myself use it exclusively for a month so that the habits would be ingrained, and took the time to go through vimtutor as well as to order and read Steve Oualline's Vim book. And when I say "exclusively," I mean it -- I switched to using Mutt for email at that time, and also started doing all code development, outlining, and more in vim. And after a month, I realized I didn't want to use anything else.

Ironically, I find myself working for a company that sells an Integrated Development Environment (IDE). As a result, I've done some test runs with Eclipse, Zend Studio for Eclipse, and even NetBeans, to see what features they offer and to see if there would be anything compelling that might make me change my mind.

One of the immediate sticking points for me is that my brain is now hardwired to edit text a certain way. I use my home row keys to navigate through a document (as it's wicked efficient), switch to visual mode to highlight text (even more fun is highlighting specific columns!), and more. This has driven me to try a number of plugins for the aforementioned editors that add 'vi' or 'vim' capabilities to them.

I've tried the following:

So far, they universally fail.

Why? Because they reimplement vi(m) keybindings, but don't actually re-use anything from vim itself. Why does this matter? Because this means the tools completely ignore the entire vim ecosystem. Vim has a wealth of user plugins, syntax highlighting codecs, filetype plugins, and other utilities -- and you can use none of them. Vim allows you to create your own keybindings, and provides a language for creating your own plugins... and you cannot use them. Vim allows you to specify your own settings in a configuration file -- these tools not only ignore the file, but have no ability to source it whatsoever.

As an example, I have bound 'jj' to the <Esc> key. This micro-optimization prevents me from needing to reach outside my home row in order to switch modes. I cannot use this in eclim. I have bound <Ctrl>-L to the linter in a variety of languages; I cannot use this in vwrapper. I use a plugin to autocreate phpdoc docblocks; I cannot use this in jVi. Basically, each of these tools provides what I consider a crippled version of vim, as I cannot do things I would do in vim.

What these tools are trying to do is make the IDE environment more familiar to vim users -- as far as I can see, it's more like a migration tool. "See -- you can make it look and act a lot like vim! Now that you're here, maybe you should try some of our other features!"

And that's where the final nail in the coffin occurs, to my thinking, because there's one thing vim does that no other IDE I've tried is capable of: it loads in under a second. I often want to look something up in my code. Do I wait for my IDE to startup? or, once loaded, do I peform a variety of mouse convolutions to find the file I want to see? Or do I simply open up vim and use c-tags to load my file in 1 or 2 seconds?

In summary, these projects fail because they make you long for something you already had: a fast, extensible editor.

So, all in all, while I think these projects are interesting, I think it makes more sense to either go total immersion in the IDE, or go back to your editor of choice. I know which one will be in my own toolbox for many years to come.

Posted by Matthew Weier O'Phinney in PHP at 08:30 | Comments (32) | Trackbacks (0)

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
Display comments as (Linear | Threaded)

Would you consider writing a post about PHP development and vim? I can't justify spending XXX dollars on Zend Studio because Eclipse PDT has always been so mind bogglingly terrible. Also, any tips on integrating ZF development with your chosen IDE (again, other than Zend Studio).
#1 Jake McGraw on 2009-03-12 09:02 (Reply)
Search my blog for "vim" -- I've written a number of posts on the subject. Also, you should google for Andrei Zmievski -- he's done some presentations on Vim for PHP development, and has some good tips as well. Finally, if you search on twitter for the #vim hashtag, I've posted some tips there.
#1.1 Matthew Weier O'Phinney (Link) on 2009-03-12 09:50 (Reply)
Um, your blog requires a string longer than 3 to search.
#1.1.1 Adam Culp (Link) on 2009-03-12 14:13 (Reply)
Sorry, I was too hasty. Adding the asterisk was all that was needed. Thanks.
#1.1.1.1 Adam Culp (Link) on 2009-03-12 14:16 (Reply)
I used to use viEclipse back before I got all emacsey, I liked it quite a bit. For a guy like me who never got the hang of vim's more advanced features that you mention and who really just missed the keybindings, it's not so bad to get a plugin that gives you those keybindings. The keybindings are possibly the biggest win about vim. Though I'll admit to not having got the hang of viper-mode yet. I should get back on that.

Getting slightly evangelistey for a moment, emacs starts up fast, but I probably already have it open anyway. As for editing over SSH, tramp-mode kicks in and my locally-running emacs opens its own shell to the server and delegates file operations to it and SCP -- I even forget I'm not editing a local file.
#2 chuck (Link) on 2009-03-12 09:31 (Reply)
There are plugins for vim that can open files using scp as well -- I typically don't use them. But often I'm doing administration on a server, and vim is my editor of choice when I need to edit a file as part of an administration task (such as /etc/hosts, resolv.conf, etc.).

I've never really given emacs much of a try, and typically shy away from vim/emacs debates as I cannot comment on the latter.
#2.1 Matthew Weier O'Phinney (Link) on 2009-03-12 09:48 (Reply)
Slightly OT: I've tried viper-mode. Had some quirks with my setup, but for a less convoluted setup, it seems to be the best option for emacs, opposed to vi-mode and vip-mode. I eventually gave up on it; for my reasons, see my post below (#9). If you want to discuss it more, I'd be happy to. Just go to my website and you can catch me on twitter or email me. I enjoy discussing editors and IDE's and am always looking to learn more about them.

Because then I'll know.... and knowing is half the battle!
#2.2 Brian Zwahr (Link) on 2009-03-12 13:03 (Reply)
Anyone that needs some top notch VIM expertise should try to attend Andrei's talks or get the hands on his VIM slides :-) Quite interesting and even for someone that's been using VIM for many years, there are still things to learn :-)
#3 David Coallier (Link) on 2009-03-12 10:03 (Reply)
While I use Textmate right now I agree that the above mentioned IDEs don't meet my needs for more reasons than just key bindings. Eclipse and its spawn take forever to load and seem to be perpetually looking for updates in the background.

Vim with some plugins and syntax highlighting does much of what I want though I really like the Textmate bundles which save me tons of time.
#4 Jim Tinsky (Link) on 2009-03-12 10:15 (Reply)
Heh - I think this is an "essential disconnect" from those who started in an IDE environment and those who started in VIM

I hate VIM - not because it's bad but because I don't use it as my primary editor, I didn't start with it, and I don't care to migrate to it. I have many people give me the same line about VIM as you gave about VIM tools for the IDE

"See -- you can make it look and act a lot like $youreditor! Now that you're here, maybe you should try some of our other features!"

And quite frankly I have the same arguments against take the time and energy to learn $new_editor. It's like the emacs vs. VIM debate - or even Windows vs. Linux vs. $other_os. I'm of the opinion there is no "best" - only what you KNOW best, are most comfortable with, and are most productive in ;-)

However I do see an additional bonus for the tools themselves that do make them a bit more useful - if you are forced to use $IDE in some instances instead of the comfortable VIM - well the bindings can help bridge the gaps in behavior so it's not quite the smack in the face change.
#5 Elizabeth Smith on 2009-03-12 10:17 (Reply)
You've hit the nail on the head. The question I hear from my colleagues is, "what features would compel you to use an IDE over vim?" To which my answer is, "None." As you so rightly point out, if you've taken the time to learn a particular editor or IDE _well_, then there's really very little to be gained by switching, and likely a lot of lost productivity in exchange.

I cannot think of a single situation where somebody should ever be _forced_ to change, either -- which is why I think the tools like those I post about here are mostly pointless. But as you and I both mention, they give a modicum of familiarity for those that do try, and perhaps make the switch a tiny bit easier. I just found myself wishing I had the full functionality, though, not a subset.
#5.1 Matthew Weier O'Phinney (Link) on 2009-03-12 10:22 (Reply)
Pida (http://pida.co.uk/) looked promising but it seems to have lost steam :-(
#6 Ariel Arjona on 2009-03-12 11:04 (Reply)
From the PIDA development team: We are going strong, coming up to a new release.
#6.1 Ali Afshar (Link) on 2009-03-12 18:33 (Reply)
What you have said is absolutely true. After all these years, Wine folks couldn't get Linux to behave like Windows. Not to blame them, I appreciate the Wine project.

As you have rightly indicated in the post, writing features similar to that of a completely different system is quite challenging even for a large community of developers.

It's like getting a lion to eat vegetarian food. :-)
#7 Sudheer (Link) on 2009-03-12 11:08 (Reply)
Thats all very true, but in my opinion you're comparing apples and oranges...

VIM is at heart a text editor, not an IDE. An IDE at heart is an environment - of which one of the components is a text editor. A better comparison would be Nano vs. VIM vs. Emacs or whatever...
#8 James (Link) on 2009-03-12 12:18 (Reply)
I'm actually not comparing IDEs to text editors -- I'm saying that plugins that make the editor component of an IDE act like a given text editor fail because they don't reproduce the full functionality. I'm comparing the editor (apple) to the emulated editor embedded in an IDE (apple).

However, I'd also argue that many text editors are already part of an environment, particularly when you work on *nix machines. Because editors such as vim or emacs can interact with the current shell, you have access to your entire system environment. Through this, I can run linters, execute a script (optionally via a debugger), find files, and much, much more. In essence, you have a larger environment than IDEs offer, as you can interact with any other process on the system.
#8.1 Matthew Weier O'Phinney (Link) on 2009-03-12 12:38 (Reply)
Ahh, I see your point now.

I can imagine how difficult it would be to emulate vim in Eclipse for example - there are so many other key combinations that may conflict. Generally when you're using a GUI, you navigate using a combination of your mouse and keyboard. I suppose when you are as used to using a CLI such as you appear to be, using a mouse could be deemed to be more of a hindrance.

I see your point about the environment too. I guess people like me are so used to just clicking a button to fire up the debugger, and it just *works*. It's down to preference I think - whether you prefer having it just "work" but having limited possibilities, or having to be more manual but have endless possibilities. I suppose the latter is more of a *nix like concept :-)
#8.1.1 James (Link) on 2009-03-12 12:49 (Reply)
As an emacs user (though I learned vi (not vim) first), I think one of the biggest hang-ups for me is switching between modes. Why should I have to go to visual mode to move around (yes, I know you can use the arrow keys in insert mode, but why when your hands are already at the home row?) then switch to insert mode to, well, insert text? I just find myself wondering why the visual mode is necessary at all, except to allow you to use key strokes that would normally just be inserted as text.

Now, that said, having to move to escape is an annoyance to me. You said you bound 'jj' to . How does that work in insert mode? Wouldn't two j's just be typed into your text/code?

Also, any enlightenment (subjective and opinionated is fine) on how visual mode can be useful would be appreciated. I've often thought of switching to vim from emacs, or at least using them side-by-side (though LISP is a big factor for me, and since I use StumpWM, written in LISP with emacsey keybinding, and Conkeror, xulrunner web browser emacsey keybindings, my entire environment is very 'standardized' for lack of a better term).
#9 Brian Zwahr (Link) on 2009-03-12 12:36 (Reply)
Er, that should be "bound 'jj' to ESC". I put less than and greater than symbols around ESC, not even thinking that it would be seen and HTML/XML/etc and stripped.
#9.1 Brian Zwahr (Link) on 2009-03-12 12:38 (Reply)
Re: 'jj' -- it checks for a delay. In insert mode, if the characters are typed quickly (within the same second, basically), then an Esc is issued. I have it mapped universally, so it's an easy macro.

Regarding visual mode, it allows me to selectively highlight text and then perform operations. You can highlight normal blocks, or you can use the "visual block" mode, that also let's you restrict which columns of text are selected. This is particularly handy if you want to delete prefixes that are common across several lines of text, or if you want to do substitutions on a set of columns.

Modal editors are primarily geared to people who like to type fast, as they allow users to stay in the "home row" on their keyboard. But they definitely take some getting used to.
#9.2 Matthew Weier O'Phinney (Link) on 2009-03-12 12:44 (Reply)
I'm fairly certain that, by "visual mode," Brian was actually referring to "normal" mode, because he was talking about navigation. If you want to know why that's an important mode, Brian, I suggest taking fifteen minutes to go through vimtutor. Experience for yourself navigating 5 words ahead, or to the end of a pair of parentheses, or the beginning of a class definition, with two or fewer keystrokes, and without having to reach for the mouse.
#9.2.1 Chris Lasher (Link) on 2009-06-12 16:00 (Reply)
I generally agree and I have just one slightly offtopic comment - I also find Esc to be way too far. I tried switching Caps Lock and Esc, only to find out that I can't really use it that way. After pondering about mapping jj and other combinations, I finally decided to go with "jk" and "kj" (you just press the keys at the same time) and I can't complain. I believe it's much (twice? :-)) faster than pressing j twice. Sometimes you want to actually write jk or kj, but that doesn't happen often, and if you set a reasonable timeout, it's not really much of a problem anyway.
#10 tasuki (Link) on 2009-03-12 13:07 (Reply)
You seemed to have inspired quite the conversation with this one :-)

I have to admit that I started out in Eclipse and tried and tried and tried to get over my hang ups with respect to its affinity for using every last resource on my machine. I finally gave up and grabbed macvim one day. I forced myself to figure out why so many hardcore fans have been made out of this one tool. I basically quit graphical IDE's cold turkey and am so happy that I did. I may take an extreme view here, but I personally think that the way that you use vim is closer to an actual communication with your computer than simply poking at things with a mouse. Yeah, it takes a bit of re-wiring in the brain but imho it's the best decision I have made with respect to programming.

Thanks for your posts on vim and vim tips, I look forward to them.
#11 Paul Shoemaker (Link) on 2009-03-12 16:18 (Reply)
I've used vim as my main development environment since 2001 and while I still try to give the available IDEs a chance, I simply can't write quality code with the same speed. I hadn't tried the vim plugins and wondered if they were useful, so you're post saved me a lot of time. Thanks!
#12 Brian D. (Link) on 2009-03-13 09:32 (Reply)
"And that's where the final nail in the coffin occurs, to my thinking, because there's one thing vim does that no other IDE I've tried is capable of: it loads in under a second. I often want to look something up in my code. Do I wait for my IDE to startup? or, once loaded, do I peform a variety of mouse convolutions to find the file I want to see? Or do I simply open up vim and use c-tags to load my file in 1 or 2 seconds?"

My IDE is there instantly that's because that's where I live.

VIM isn't project aware and that's why it fails. As it kills functionality like refactoring and more fancy stuff.

"I think it makes more sense to either go total immersion in the IDE"

kinda hits the nail on the head, that being said you probably make the VIM user better at home by bringing the commandline into the ide rather then trying to make shotcuts exactly the same or bringing vim-plugin's in that will only create more mismatches.
#13 michael on 2009-03-15 13:32 (Reply)
I don't want to have an IDE on constantly. If I'm not using it, I don't want it wasting resources on my machine.

Vim *can* be project aware via plugins such as Project (I've blogged on this before). While I may not have built in tools like refactoring, I do have access to tools such as phpcpd (http://github.com/sebastianbergmann/phpcpd/) and phpmd (http://phpmd.org/), which may arguably give me better functionality.

But this is all beside the point. The point of this entry was to decry the development of IDE plugins that make the editor behave like vim. Since they do not mimic the full functionality of vim, they leave vim power-users actually with yet another environment to learn.
#13.1 Matthew Weier O'Phinney (Link) on 2009-03-15 13:55 (Reply)
I'll jab at the first bit by commenting that if your not using it - are you still working? What I was really trying to illustrate is that the IDE-ppl have an entirely different type of Zen.

Which is why the "go total immersion" as you mentioned hits home. (Or stick to Vim) If you don't immerse yourself your not going to change your Zen or make any real use of the IDE and its then pretty certain that you will only lose.

It would be interesting to emerge myself into a full fledged VIM environment. If just for the sake to be able to better understand the perspective of a Vim user. Though the discussions about Vim vs IDE have been exceedingly rare lately.

Still I've seen those plug-ins ease the transition - yes in the end they where tossed out. But it helped ease the pain while they lasted.
#13.1.1 Michael on 2009-03-15 23:39 (Reply)
Hello,

Please add your site at http://www.sweebs.com. Sweebs.com is a place where other people can

find you among the best sites on the internet!
Its just started and we are collecting the best found on the net! We will be delighted to have

you in the sweebs listings.

Regards
Kris
#14 Kris (Link) on 2009-03-16 05:50 (Reply)
Hello Matthew,

I'm the developer of Vrapper and I have the urge to step forward now and defend my plugin.

While I agree with what you are trying to say, I think it is quite harsh to say that Vrapper fails. You seem to think that my intention is to completely replace Vim, which is wrong. As stated clearly in the documentation I wrote for Vrapper (http://vrapper.sourceforge.net/documentation/?page=1#theinterestingstuff), I do neither intend nor recommend to use Vrapper/Eclipse as primary text editor.

There is nothing that Vrapper itself does better than Vim. However, the simple feature set allows to just "wrap" existing Eclipse editors instead of writing a new one, which means you do not lose any of the features that an Eclipse editor provides. If you do not need those features, there is no reason to use any kind of plugin - just use the real Vim as external editor in Eclipse (that is what I do for almost everything non-java).

Ultimately, you should not choose between Vrapper and Vim but Eclipse and Vim. If you would choose Eclipse over Vim anyway for some task, then Vrapper is a nice addition of features. And of course you do not really have to choose - you can use a combination of both.

In my personal experience, I can say that using the Java editor in Eclipse got much faster since I started using Vrapper. So ultimately, I did not fail but achieve exactly what I wanted - a speed-up in the Eclipse editors.

People who are really experienced with Vim (like I guess you are) will of course miss a lot of things - but I do not understand why you would use something like Vrapper then anyway, as you can use Eclipse as IDE with Vim configured as external editor and have everything you want. There is also the Vimplugin (http://vimplugin.org/) which embeds the original Vim as on OLE component in Eclipse.

Vrapper is not designed to migrate Vim users to Eclipse, but to give Eclipse users some Vim functionality.

What puzzles me a little is that you use Eclim as an example of a plugin which reimplements Vim in Eclipse, as it is pretty much the opposite. It lets you control Eclipse via the command line in Vim. That sounds very much like something you are looking for. :-) Maybe I am wrong as I did not use it much, but it sounds like it does not break any existing features of Vim.

To sum it up, I agree with what you write about the "vim ecosystem" but disagree that those plugins are useless because of it. They may not be what you want, but this does not mean they fail as their purpose is just something different than you want.

Anyway, thanks for taking interest in my plugin. :-)
#15 Matthias Radig (Link) on 2009-03-16 08:03 (Reply)
Have you ever tried Vimperator or any of it's siblings? It's an addon for firefox that turns it into a vim like browser.

https://addons.mozilla.org/en-US/firefox/addon/4891
http://vimperator.org/

You might like it :-)
#16 Josh on 2009-04-01 05:27 (Reply)
Yeah, maybe you should go back and read Eclim's homepage. Although it does provide the ability to embed vim, it's got the opposite goal (IDE features WITHIN vim) and only provides the embedded editor since it incorporated an old projects code called 'vimplugin'.
#17 huh on 2010-01-16 07:36 (Reply)
Yeah, I'm aware of that -- I just kind of clumped it in with the rest. One of the problems remains, however: you need either an instance of Eclipse open, or an instance of the eclipse server, for it to work -- leading to additional resources. That said, it has a benefit over the other offerings: you can keep your custom vim profile -- which might include a number of key bindings and macros -- while getting many of the benefits of Eclipse.
#17.1 Matthew Weier O'Phinney (Link) on 2010-01-16 11:12 (Reply)

Add Comment

Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA