@bozhidar I think this is still important https://github.com/nrepl/nrepl/issues/315 but it is already an open issue on nrepl. Should I move it to the spec issues or is it out of scope?
It’s still in the cards for the Clojure nREPL server, but I’m not sure if this will make it to the spec. One of the considerations we have is to have a spec that’s relatively small, so implementing compatible servers is not painful in certain environment.
Is the spec brand new, or has it been published before?
@neumann It’s brand new. We have been discussing creating a formal spec and some standard client and compatibility test suite for ages, but real work in this direction started only a few months ago (@technomancy drove the efforts initially). There are still quite a few open questions that we need to address, but I thought it was probably a good idea to publish what we have so it’d be easier to have a conversation with people interested in contributing to the spec.
I’ll try to carve out some time to work on this myself in the months to come - my recent work on https://batsov.com/articles/2026/05/20/neat-a-language-agnostic-nrepl-client-for-emacs/ was a pre-cursor to this. I plan next to put together some simple “standard” client and perhaps some alternative (and simple) reference implementation (that’s not in Clojure).
> implementers may propose a draft extension to the nREPL protocol Oh boy... where do I start??? 😆