You can count me as one of those who simply don't like modal editors. Every vi(m) user has had the experience of pasting something in while in command mode or typing commands while in editing mode. It's disruptive and annoying (IMHO). Obviously YMMV.

But take the poster's example of changing parameters. Let me tell you how I do this in IntelliJ:

1. Click anywhere between the parentheses; 2. Press Ctrl+W (context-sensitive selection) repeatedly until I have everything within the parentheses; 3. Type the new parameters.

Now some might object to the mouse use here. There is a belief that the keyboard is faster, which seems to at least in part be an illusion [1]. Anyway, (1) can be replaced by any number of keyboard navigation techniques. Incremental search tends to be my "go to".

The one big use case for vim/emacs for me is the ability to use them over SSH. That's actually pretty huge but I won't use either all the time just for that.

At the end of the day vim (and emacs) are just text editors, which is fine, but you see this limitation all the time. Regex based syntax highlighting will have funny edge cases (emacs is a little different here I know).

An IDE is built to understand code constructs and concepts like the context-sensitive selection I mentioned above. Being able to move a java file and have it update all my imports and packages. Being able to auto import when I start typing a class name. Code templates (eg type "iter" or "itar" in IntelliJ then hit tab when you want to write a loop).

The amount of mental effort that seems to go into recreating an environment you get for free with an IDE is mind-boggling to me. By this I mean the constant tinkering with plugins and extensions.

Unfortunately many vim/emacs diehards use Eclipse as a strawman argument against IDEs ("I once used Eclipse and it was slow thus IDEs suck") when Eclipse is (IMHO) at best a medicore IDE with a lot of warts.

The other area where vim/emacs have survived is with the C/C++ family of languages (Visual Studio notwithstanding for Windows users). That's because tooling in this area has been pretty basic. I applaud Jetbrains' recent CLion effort.

The problem here is that the C++ grammar is so incredibly complicated it makes tooling difficult.

This is one reason why I appreciate the design goals of Go: simple grammar leads to easier tooling and faster compilation.

[1]: http://ux.stackexchange.com/questions/30682/are-there-any-re...