Yeah there are a lot of interesting things you can do if you design languages around an editor. Like complete, recursive type inference, so you don't have to annotate types on function signatures, but the editor can display them, which is very useful, or showing what exception can be thrown even if the language doesn't make it explicit. This works out great when the editor is available on the platform you need and working.
F# is a language this is a lot like this, and I've recently been unable to get the editor with these features working in Linux, and it makes it rather horrible. If you had to remote in to a server and use vim, it could be rather horrible, and so on.
If we can get something like the language server idea working, really well, on all platforms and supported by all editors, then designing languages around certain IDE assumptions would more often be a good idea I guess.
That's all very true, and it's sad that we haven't explored this space more.
It's a nice in-between something like a Smalltalk image-environment-IDE / Lisp Machine and a dumb IDE/editor that starts from source code and has to parse into AST into its own...
F# is a language this is a lot like this, and I've recently been unable to get the editor with these features working in Linux, and it makes it rather horrible. If you had to remote in to a server and use vim, it could be rather horrible, and so on.
If we can get something like the language server idea working, really well, on all platforms and supported by all editors, then designing languages around certain IDE assumptions would more often be a good idea I guess.