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.
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.
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).
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.
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.
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);
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.
for a good overview at the history of vim integration, check out http://www.freehackers.org/VimIntegration
the only really good one i've seen is jvi [http://jvi.sourceforge.net/], which is a straight-up port of vim to java as a netbeans plugin. emacs's evil mode [https://gitorious.org/evil/pages/Home] is getting there too.
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.)
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 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.
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.
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.
* 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.