These days, out-of-process, editor-agnostic code analysis engines or "language servers" provide many IDE-like features to any text editor that is scriptable and can do basic IPC. Examples include:
* Tern for Javascript
* rtags for C and C++ (I use this all day, every day, at work, it's remarkable how good it is)
* Go's oracle tool
* racer for Rust
* tools.nrepl for Clojure
All of these have solid editor support; at the very least, a good package is available for Vim, Emacs, and Sublime Text.
IDEs tend to be all or nothing. I'll open one on occasion for a particularly nasty debugging session. I wish, though, that half the development effort going into IDEs were instead directed towards better editor-agnostic tooling.
> I wish, though, that half the development effort going into IDEs were instead directed towards better editor-agnostic tooling.
In principle I agree. I like the thought of composable tools. But I wonder in practise. I'm trying to picture the vast array of facilities integrated in IntelliJ (analyses, many refactorings, syntax-aware snippets, amazing code navigation, structural search & replace, data flow anaylysis, syntax-aware select, omnipresent code generation, etc) integrated into a text editor via external tools. I suppose it could be done, but it seems unwieldy. And with how much work (setup and maintenance) on the part of the user? How often would things clash or need fixing? And with how much discoverability (a critical feature of IntelliJ)?
What I do know is that working with code (not mere text!) in IntelliJ is quite a joy for me. For now, I'm glad someone has built it, even if the 'ultimate' composable set of tools might have some advantages.
Having worked extensively with primareliu Java in IDEA, I have come to consider syntax something that is more a presentation layer issue than something actually important to the core differences between languages.
I suspect that this shift in what I consider important parts of a language is at least partially down to an IDE that for the most part lets me think about the concepts I am expressing, rather than their superficial expression as text on a computer screen.
This may be true in for single heroic innovations, but sometimes the 'new' can emerge from successive refinement. I find this to be the case for IntelliJ. Working in it in static languages (at least the ones it knows well) just feels to me quite different from merely 'editing text'. The depth of code intelligence, combined with hundreds of small refinements in the way commands like refactoring work, affords a sense of working with syntax and structure, not 'text'.
> The speed with which we write text as programmers is not the limiting factor of how much software we can produce and never has been.
Again what IntelliJ adds for me isn't 'speed', but a cognitive sense of moving up the abstraction hierarchy. I'm thinking in terms of things like 'add a parameter to all call sites' much more than I am editing 'text'.
(caveat: I did use vim quite extensively many years ago, but never got beyond the learning shortcuts phase with emacs. It's possible either of the big 2 have similar refactoring and code intelligence packages available now)