You must have used some pretty shitty IDEs then. I use IDEs for the productivity boost, owing to code completion, fast lookups, folding, integrated documentation, syntax highlighting, integrated build system, interactive graphical debugging, integrated source control, project based search, GUI tools, etc.
Of course, all IDEs have their design flaws (like any other piece of software), but the benefits are compelling.
I use IDEs too — sometimes — but there's a dark side to each of the things you're describing above. Here's the devil's-advocate argument.
If code completion is speeding you up, it means you're writing code with a lot of redundancy in it. But the slow part of programming isn't typing the code in in the first place; it's reading it later. If the stuff you're putting in your source code is redundant boilerplate that code completion can put in there for you, then it's going to make it hard to read the code later, when you need to find the part that you actually typed, because it has a bug in it, or because you need to change it.
If fast lookups (I assume you mean meta-point, quickly jumping to the definition of an identifier from a mention of the identifier?) are speeding you up, well, maybe you're getting into a codebase you don't understand very well, because you're just starting to work on it. (Although these days grep is pretty fast.) Or maybe your codebase is an overcomplicated nightmare with too many layers of indirection, costing you comprehensibility even despite the wonders of meta-point.
If folding speeds you up a lot, maybe your code is way too deeply nested, or you have a lot of irrelevant stuff mixed in with the stuff you're trying to read.
If integrated documentation speeds you up a lot, maybe you're programming to an API that's too big to memorize, which means you're going to make errors when you call it and then not be able to see them when you read the code.
Syntax highlighting is nice, but it matters most when your code is poorly laid out and unclear, and then it doesn't make your code easy to understand.
If you're spending so much time in your debugger that it matters a lot to you whether the debugger is an "integrated graphical debugger" or not, you're wasting a lot of time. Debuggers are indispensable when you're exploring a codebase you don't understand at all. (Although, in that case, the best one is probably IDA Pro, not part of an IDE.) But on code you write yourself, use unit tests and code reviews to minimize the number of bugs you have to debug, and in many cases, logging is a much more efficient way to track down bugs than a debugger, because you can see a whole run at once, instead of a single point in the execution. As an extra-special bonus, logging lets you track down bugs from production that you can't figure out how to reproduce on your own box.
If IDE GUI tools are saving you time, any time at all, your GUI library sucks and you should use a better one. Also, you're probably making shitty GUIs, the clicky equivalent of the IRS 1040-EZ, joyless bureaucratic crap, because GUI tools don't help you when you're trying to construct things like kseg or Inkscape or the GIMP. HTML and CSS, or for that matter Tk, allow you to produce those soul-destroying forms with less effort than some crappy drag-and-drop IDE. That's why HTML has replaced Visual Basic in modern use.
As for project-based search, I keep each project in a directory of its own, and then I can use grep -r or ack to search the project.
As for integrated source control, I probably spend about five minutes per hour interacting with my source control system, except when it completely breaks (in which case IDE integration is generally pretty useless).
If your integrated build system is saving you time, then you have way too much complexity in your build scripts, which are a part of your code that don't add any functionality to your product.
In short, the lovely features you're describing are real productivity boosts — but each only exists to compensate for an even bigger productivity killer, and then they only rescue you partway.
⁂
Do I believe that? Well, halfway. I use M-/ in Emacs (code completion) pretty often. I use integrated documentation because there are some APIs where I never can quite remember the arguments, including sometimes things I've used for decades. I use meta-point in Emacs under some circumstances; it's pretty much a necessity for some codebases. (And I use it often when I'm exploring unfamiliar code.) I always turn on syntax highlighting in any editor, because whether or not it improves my productivity, it's pleasant. I don't use folding, but it's not uncommon that I wish for a hotkey to fold all the comments in a piece of code. I have F5 bound to 'recompile in Emacs for the times when I'm playing around rather than implementing something well-defined. I use GDB's Emacs integration. Also, I use the fuck out of Firebug.
Basically I think it's stupid to do stuff manually that could be automated. Compilation is a good example: by using a compiler, I automate endless hours of fiddling with register assignments. But I think that eliminating work is even better than automating it.
