Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Clojure(Script) Language Server #2
I would like to start an open discussion about tool support for CLJ(S).
I started writing a Language Server Protocol (LSP) implementation   for CLJ(S). I have started to implement the basics and can now feed CLJS compiler warnings/errors back to an editor. This uses the
Obviously this isn't very useful without editors that support this protocol. The above screenshot is taken in Visual Studio Code since it supports the LSP out of the box. It does not however support nREPL or any other REPL for that matter. Fundamentally the requirements of tools are represented better by a dedicated protocol anyways than just a REPL. Long discussions  about this have happened in the past. One point made by Rich Hickey stands out to me:
nREPL has become the de-facto standard for tools to communicate with the runtime, whether they actually multiplex everything over one connection or use multiple connections I don't know. At this point I'm strictly talking about tooling related things the LSP would cover. This includes code completions, code navigation, formatting, documentation lookups, etc. It does not cover a REPL and shouldn't since that has very different needs than tools have (as mentioned above).
nREPL vs JSON-RPC
Assuming for now that the editor will connect to a dedicated TCP port with a dedicated protocol. The protocol is about framing messages between the LSP and the editor. This must support request/response semantics as well as simple fire-and-forget notifications in both directions.
nREPL or JSON-RPC?
The question now is which protocol we (the Clojure community) should use. Most tools already support nREPL but not LSP. There is growing support for LSP   and using this protocol enables talking to other languages as well.
Please note that this has absolutely nothing to do with a REPL, this is strictly about editors communicating with the server and which protocol to use.
I understand the idea behind this, but that's something that has to be implemented by editors themselves - Emacs has to support this protocol, not CIDER for instance. I'm all for having standard tooling, but I'm not familiar with this protocol and have no idea how extensible and flexible it is.
@bbatsov there is a emacs client already. The protocol itself is easily extensible, how extensible and flexible the client you are using however is left to the client. I don't speak emacs but you could probably connect that to my server today.
Forget the link to the JSON-RPC spec. Which methods are defined is left to the implementation, so the Clojure implementation can easily add Clojure specific methods. This would not interfere with what the editor would want to do. The LSP standard defines common things that are more or less relevant to each language.
The LSP protocol has capability negotiation built in via (intialize, registerCapability), look for
The protocol is rather new so I would still consider it ALPHA despite the v3 version tag.
At this point it would be better to start from scratch. Removed half of the code and moved some things around. The proof-of-concept wasn't anything I would build something real on, it was just about the proof that it can work.
I still have so many other things on my todo list and LSP is very very far down. :/