> With languageserver and the other kind of refactoring daemons available for a whole host of languages nowadays these editors are much closer to IDE's than ever before.
Most likely true, though i think the "I" part of "IDE" is woefully ignored and (at least to me) is much more important than a hodgepodge of barely related programs strung together with duct tape.
That's precisely what every single python IDE does. They take isort, black, jedi or whatever other engine together and stitch them together in a user transparent way.
Omnisharp was literally the attempt of MonoDevelop to create an open source alternative to the Resharper engine.
The completion agents for VIM or VSCode do the presentation layer for the lower layer(the language server daemons, or custom completion agents. YouCompleteMe however is all that together in one not as fancy but I like it).
I get where you're coming from, but basically the difference is that vim by itself is a raw editor and until neovim came along never made an effort to merge the functionality that was required for something like this to happen in a nice fashion.
Editors like Oni are basically distributions like VSCode with defaults that are more inline with what you say plus a nicer presentation layer.
Yeah well, it isn't like Python IDE are much better :-P. I think in general most languages with unix-ish background do not tend to have truly integrated development environments as unix was always about stitching together stuff. Only Borland somewhat managed to make real integrated environments for their C/C++ tools and even then it wasn't as good as the stuff they had better control over (turbo pascal, delphi, etc).
Java and NetBeans is (or was, before Oracle botched it) probably the best IDE (in terms of integration) for a toolset with a unixy background.
Though none of those compare to something like Smalltalk, Lisp or even Microsoft's QBasic and (pre-.NET) Visual Basic.
Note that i'm talking about how integrated the IDE is with the language and its tools, not about how good or bad the language is.
I think this isn't about unix tools or philosophies. It's about the fact that for a very long time these big monolithic projects didn't really allow any integrations.
Vim didn't allow integration because there was no way interface to it, and it's not an easy codebase. Neovims work is proof of that. C++ compilers didn't allow integration because they were big monstrous projects and when you need to do proper c++ indexing you basically need to compile the whole project.
For C++ this changed with clang and even for clang it took a lot of iterations and bugs inside of libclang to allow for this capability.
Naturally one of the best C++ IDE's was therefore also by the producer of their own compiler (Visual Studio).
These boundaries are slowly fading, so these arguments are kinda moot. A few examples:
No i think it is actually about philosophies (or at least a way of looking at how software should be made) - again, i point out to Borland (whose IDEs were always provided a way more integrated environment than anything Microsoft ever did - e.g. for C++ MSVC always called out to a separate compiler program that had to reparse/restart its state for each file whereas BCC had the compiler as part of the IDE executable that would keep state across compilation in memory and even use the editor text buffer for 'input' if there was one instead of loading a file from disk) and Smalltalk (where the IDE and runtime are the same thing, you are modifying a live environment with tools written in that same environment instead of cold-running everything from start).
libclang might be a bit closer but it still is something separate from whatever IDE it is used for.
Honestly i do not believe it is even possible to what the sort of integration i'm talking about by stitching together separate projects no matter how many extension points and hooks those projects provide - by definition they aren't made with a singular coherent vision where everything is meant to work together, instead each project has its own idea of how it should work.
MSVC could in theory be able to do that since the IDE is made by the same company as the compiler, but in practice the teams behind it are probably acting as separate "sub-companies" inside the bigger organization. They're not seen as a single "C++ development environment" project but as two separate projects that happen to communicate with each other.
I'm not sure if 'philosophy' is the proper term here, but it is certainly about how you believe that software should be made and having that in mind at all times when designing it at all levels - be it the functionality to provide or how that will be implemented (e.g. a compiler that runs as a simple standalone application can just use globals for the state and perhaps not even free memory at shutdown - see dlang as an example - whereas a compiler meant to be integrated as a library cannot do that).
As an example, for a Borland-like approach (at least based on my understanding of it), adding a language extension to -say- provide meta-data for classes wouldn't be something that only the compiler developers cared about, but something that the developers of the compiler, the debugger (for being able to display the meta-data), the IDE (for editor auto-completion and automatic code editing - later Borland IDEs could modify the code - and debugger UI), the framework library (for taking advantage of it and providing a 'best use' scenario), etc. And all of those would influence the new functionality instead of being something that was added by the compiler team and then the rest would have to support (as it is done by pretty much every language that only exists as a standalone compiler or interpreter without any concern for IDEs, debuggers, UIs, etc nowadays).
Most likely true, though i think the "I" part of "IDE" is woefully ignored and (at least to me) is much more important than a hodgepodge of barely related programs strung together with duct tape.