There are still 2 things that I can't give up that IDE's do better than vim (in my opinion):
1. Refactoring operations. I have yet to find a vim plugin that has the extreme refactoring awareness I've become accustomed to in IntelliJ IDEA and Eclipse. And writing a macro to do it for you is not the answer, because these tasks are non trivial to do a.) correctly, b.) in the general case, and c.) across an entire codebase. There's a reason people have sunk a gazillion years and R&D dollars in to creating IDE's, and some bullshit vim macro that I put together mid-day on a Thursday because I need to extract a method isn't going to compete.
2. Super-powerful auto completions. I get that vim has code completion plugins, and most of them are good (I'm currently using YouCompleteMe). But they aren't great. IntelliJ has it's legendary "index the world" mentality, and is really great at fuzzy match finding. Eclipse is a little clunkier, but its ability to drop in the entire method signature and provide tab-stops for quickly filling in the parameters is a boon.
The majority of my bias towards these features probably comes from the fact that I write Java code for a living at my day job, where the "documentation" is actually the code completion popup 90% of the time and most file operations or refactors are accompanied by some degree of boilerplate that is handily automated. Say what you will about verbose code and "enterprise" languages, but learning an API as you go by mindlessly mashing Ctrl+Space and skipping the inheritance/implementation rain dance is a huge productivity gain.
I do all of my C/C++, Haskell, HTML/CSS/JS, and Ruby in vim, where I have a pain-stakingly customized pathogen setup that I sync across all of my computers (personal and work). Code completion is good enough, between YouCompleteMe and ctags, but I still miss refactoring something fierce. But if FP Complete releases their Haskell IDE tomorrow and it isn't completely offensive to look at (Leksah!), has good refactoring, and has good code completion, I'd jump ship in a heartbeat.
I don't think that the whole IDE vs. vim/emacs war is real. I think that they're two completely different tools that are good at very different things; I will not argue that I am way, way, way faster at just editing text in vim; EasyMotion, ctags, never having to use a mouse... I love these things. But anybody that writes off an IDE without fully understanding just how powerful the two features I mentioned above can be when dealing with multi-million loc codebases is being narrow minded.
I'd rather have a language that didn't demand lots of tooling. Lots of tooling is expensive, unreliable and a time sink.
Which is why I like vim (and have used it for 16 years) :)
Many times I have thought that len was a method on any string...
Jedi seems to work as intended, but it crashed occasionally so I uninstalled. I'm fairly certain that if you really want autocomplete, you can get it working with vim.
Its helpful, but not the same thing!
This is why for me "free-form refactoring without relying on fixed-form refactoring routines and plugins (i.e not just a glorified search and replace)." (which is a comment by myself made 6 days ago, that actually makes the same point as TFA) is extremely important.
As for discovery through autocompletion, I find my need for it has been greatly reduced these last years, with a growing number of APIs that "make sense", hence discovery happens in your head, not on the screen. If the API is obtuse to the point it doesn't fit in my head, then I usually need the doc so I'll have it open nearby anyway.
I use the VSVim plugin in Visual Studio and IDEAVim in IDEA/RubyMine and they work great (ideavim is kind of lame as it has no real keymap support, but its better than nothing).
Yes! This is the crux of the confusion. Working with a multi-million LOC codebase is a very different problem than a 10,000 LOC codebase. Java+IDE is better for the former; dynamic language + text editor is (usually?) better for the latter.
When people voice angry opinions about static vs dynamic languages, and IDE's vs text editors, they should preface with how many lines of code are in the typical projects they work on. It just changes your working assumptions.
New sig for me on forums ; )
Paraphrasing Rich Hickey: everytime you're using a "pattern" and have your IDE generate code for that pattern for you, then it means: "I have run out of language" : )
Bonus points if you use Heroku/EC2 or AppEngine and ignore the "giant ball of mud" that is a critical reason your business was able to launch.
File > Preferences > External Tools
Parameters: +$LineNumber$ "$FilePath$"
Working Directory: /Applications/Emacs.app/Contents/MacOS
Then I map a key to open this (Cmd-E)
On the emacs side, I have the following to pick up changes to an open buffer that were made in Intellij
I tried solutions for Eclipse back when I used it, but I couldn't find one that I liked.
Got tired of tiled windows crowding each "perspective", and constantly reaching for the mouse.
BUT there's light at the end of the tunnel: there's eclim (eclim.org), which allows you to use vim (the real one) as the text editor for Eclipse. Or if you want you can run Eclipse in headless mode and then have vim transparently contact the (local) eclim server and suggest you, right in your vim, the autocompletion hints from Eclipse etc.
As an aside...I always sucked at the speed part. I have always been a 2, maybe 3 finger typer, throwing in a pinky for CTRL and a thumb for the space bar. While my vimming is pretty fast, typing long segments is embarrassingly slow. Have any of you overcome this after > 10 years of bad habits? How did you do it?
Don't look at the keyboard, either. Just practice this for a little bit every day (re-type a blog post or two, including the source code) and you'll get the hang of it.
I had a secretary handing my arse to me... So after ten years of bad habits I decided to learn the proper way. She showed me the basics (which are really super trivial: it's so easy that a five minutes YouTube video about how to touch-type should get you started) and then... Practice. Practice. And practice.
And I did buy a split keyboard (warning, there are two schools concerning where the '6' is located and there are even very rare split keyboard who very intelligently did put the '6' on both the left and the right part of the keyboard, so that everyone's happy : )
Buying a split keyboard kinda helps.
After three months I was back at the speed I was before. Then I started typing faster.
It's not so much about the speed: it's about the economy of hand and fingers movement too. I'm sure it's better from an RSI standpoint.
You need to force yourself and keep your eyes on the goal: become faster than before.
Don't mind the obstacles: the very beginning is going to be the most painful.
Buy a real keyboard too: my keyboard / chair / monitor are my physical tools which I use all the time. I spent $$$ on them.
Now the issue is that a good split keyboard is very expensive. ANSI Cherry MX 5000 go for about $500, split IBM Model M15 will settle you a good $1000 to $1500, etc.
Junk like the split MS ergo 4000 have a nice shape but are, sadly, using super shitty rubber dome keyboard.
If you spend your life typing on a laptop then you're destroying your fingers' joints with the ultra-low profile scissor switches.
I'm using a HHKB Pro 2 on my workstation and I hook it to my laptop. Topre switches. Amazing stuff for about $300.
Now that I know how to touch-type I don't really care about my keyboard being split or not.
In intelliJ: oh I need to introduce a new parameter here, cmd-f6 -> add a new parameter, set a default and it does it across the entire codebase.
Another key press and it runs all the tests again.
But, IntelliJ (or Resharper which I use) is only good for the language they are written for. There are quite a few times where Resharper doesn't have what I am looking to do OR I am working on language/text where there is no Resharper or equivalent [especially for dynamic languages]. In such cases, Vim is a god send. And the best part is that once you know the Vim language, it can be used to edit any text (programming or non programming).
Does the IDE have a menu item / command to move 3 lines up into the end of this if/else block?
There are 2 ways to look at this problem, specialized IDE vs generalized editor. Both are right, at times. (I personally like to use the vim plugin within NetBeans)
Oh, example of moving the lines just after an if/else into the block:
(assuming sitting on the first line of to-be-moved text, which is just after a close-curly or end line)
Delete the 3 lines: 3 d d
Move back up 2 lines: k k
Paste the 3 lines: p
Indent the 3 lines: 3 > >
9 keypresses, no reaching for the right side of the keyboard, let alone a mouse. About is fast as you can think it, the block of lines disappear, the cursor moves back to the new block, the lines reappear, and then slide right. (ignoring the clumsy autoformat that most IEDs, er, IDEs want to inflict upon your code, I'll do the indent myself, just 3 keypresses)
OK but why exactly does a new parameter with a default need to be repeated at different places across the codebase? Because you're using Java and Java is incredibly verbose and requires you to do crazy stuff and you end up with a super-complected codebase where instead of passing messages around you're actually telling objects "do this", "do that" and then when you have one parameter to a method you're in a world of hurt (because that method is used from different parts of your spaghetti codebase).
In Clojure, for example, you'd simply pass the parameters in an associative array (a map) and, even better, when you're constantly passing through the same set of parameter you'd simply wrap the method + its common parameters in a higher-order function and then you pass that higher-order function order. This makes for incredibly shorter codebases and incredibly easier refactoring.
Don't get me wrong: at 75% off during doomsday I did buy my IntelliJ IDEA licence but you're foolish if you think that the "text editor" part of IntelliJ is anywhere near close what vim or Emacs do offer you.
Also what's really great about Emacs is that you can add functionalities yourself to the "editor". Wanna run unit tests automatically and see the result in another frame/window/buffer? That's trivial to write.
No later than yesterday I missed IntelliJ's "goto declaration..." feature. I wrote a quick defun in elisp that had... Seven lines of code and did 90% of the job. Sure people are going to hard that it's for those 10% cases where my script doesn't work that IntelliJ really shines but that's not the point. The point is that you can program Emacs to suit your way of working.
You adapt vim / Emacs to yourself. With Eclipse / IntelliJ you have to adapt yourself to the IDE.
Vim has been around, will be around, and is available pretty much every where and has a giant community. That's the point.
vim is on pretty much every linux box. Eclipse isn't.
'The real power of vim is its proven staying power' is a non-argument, today I work on stuff that didn't even exist 10 years ago, there is no guarantee vim will be even usable for the sort of work you will be doing in a decade, and for sure there is no guarantee it will be the best choice. both vim and eclipse are here to stay for the next years and both have a lot of support.
there are lots of reasons to learn/use vim, but a 10 years longer historical consistency isn't one.
btw, I know vim is amazing. I'm arguing the arguments, not the case.
I can understand that people "force" themselves to go to the gym because there are obvious benefits to it, but I keep wondering why developers "force" themselves to use Vim. It's like playing and mastering a very hard videogame, except it's not a game and it's not that much fun to learn.
You can also say the same thing about playing an instrument. It is hard, and at the beginning you can't get any pleasant sound of it. You have to stick to it a little, keep practice, and everything starts working eventually!
(I'm of course not implying that everybody will find either of those tasks unpleasant).
At first I found that the speed and ease allowed me to code faster and longer. Later I realized I was making mistakes more often, because of how little thought I needed to put into editing. I think there is a fundamental limit to how fast I can get ideas from my brain into code, and the limiting factor has never been my input method. I still prefer working with an advanced input system, but I now treat it the way the OP does: like a Samurai with his sword. Sit back, relax, think, then strike. Afterward take a moment to read over what just happened and make sure it is correct.