3 ms·

> 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 intelligenc

> 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'. 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.

crispinb 9y ago
The only one of those I have tried is tern, which didn't come close to IntelliJ's analysis, but obviously Javascript's a harder beast in this respect than Java, kotlin, Objective-C etc. > 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.

crispinb 9y ago

The only one of those I have tried is tern, which didn't come close to IntelliJ's analysis, but obviously Javascript's a harder beast in this respect than Java, kotlin, Objective-C etc. > 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.