Here I come again about the Language Server Protocol
I’ve seen support for some core language features in editors lag a bit behind the releases of the language. It seems a given that most recent languages are putting some effort on the language server protocol as a means to unite the “experience” of editing source code in any editor.
Rust, JavaScript, Java just to name a few… Even Erlang has a language server in development in its core Github organization (sourcer). There is a huge list now on langserver.org.
The advantages, in my opinion, are these:
If you like Atom, VS Code, Emacs, Vim, IntelliJ and etc… it is easier to plug the language server with the editor frontend than to create your own language analyser, which will probably lag behind new features. Alchemist-server and elixir-sense are awesome projects (which I am really grateful) but they usually lag behind in support because they are not core.
You would probably get support for more editors that are not “officially supported”.
New language features would “automatically” be supported in the editors (like formatting, new core syntax like, say, “with” and so on).
The obvious disadvantage is that it would make the core team responsible for another piece of source code.
Even though, if we had good core Erlang and Elixir language servers, the experience in any editor that supports it would be awesome.
Anyway, it is just something that is on my mind for a while and I hope on the minds of more people.
ElixirLS works well and it’s up to other editors to simply support the language server protocol if they want to tag along. I don’t know that we need it to be part of the core team and I think unless the person/people working on it gets paid specifically for that it doesn’t necessarily make a difference.
It seems vim-lsp is misusing the protocol in that case according to the issue. ElixirLS working fine with VS Code (which uses the protocol correctly, presumably) would indicate that’s true.
Elixir-ls is a really awesome project. The thing is it will never get support on time of release new versions.
I still think that making it a core project would allow the project to evolve along with the language itself. Right now, Elixir-ls is awesome but not perfect and it is based on elixir-sense which is a project of analyzing the core AST. This kind of task feels to me like part of the core language.
Anyway, I think all the work we have here already is really nice. Just hoping for it to become even better.
There’s a saying that things go to stdlib to die - it’s very hard to develop or change libraries when they are in standard library, because of the slower release rate. Elixir-ls is still very well into development phase, changes often and implements new features all the time. Even because of this, it’s not a good candidate to include in core. Maybe once it stabilises, this should be revisited, but I’m convinced now it’s not a good time for this.
In the transition from 1.5 -> 1.6 was there anything unsupported by ElixirLS? I recall ElixirLS prompting me to update to 1.6 before it was officially released to get formatter support.
I agree with you, but I got the impression that @victorolinasc suggested that a LSP server was adopted as a core project, not merged into stdlib. Like how GenStage/Flow are (IIRC).
First, thanks for the support on ElixirLS, feels good to see people use and appreciate it I agree with @michalmuskala that it doesn’t belong as part of Elixir core for the time being. Unless that means someone (not me) is going to start working on it full time, it would probably end up slowing the release cycle without much benefit. Also, it seems to me to be a little too broad to be a “core” library, since it pulls in dependencies like JSON and Elixir Sense which would then need to be core projects too, I think.
The core Elixir team have been supportive of the project, in particular helping me add diagnostic returns to the Mix compilers in Elixir 1.6. So if it really does need support from the core team in the future we can continue to make that happen
