@ingy Feel free to add it to the nREPL clients list here https://nrepl.org/nrepl/1.0/usage/clients.html
It’s a server. 😀
Lingy currently has a (hardwired, non nREPL) CLI REPL with some pretty cool features. I'll make an issue to migrate it to the nREPL model as a proper nREPL client, once the Lingy nREPL server is stable.
Then we can add it to that list.
Roger that!
First I thought it was a Perl client for nREPL, so my bad!
Understood. And that's what I'll make it into (distributed on CPAN as Lingy::REPL separately from Lingy) when the time is right.
I wonder if spurious line/col info is a known bug / something that has ever been worked on?
e.g. I'll get 1:8432 for a {:op "eval" :code "foo"} where "foo" represents a var that doesn't exist
a more real-life case being Syntax error compiling at (test/orchard/misc_test.clj:1:8382) (where that file doesn't have that many columns)
more context: https://github.com/clojure-emacs/cider/issues/3331#issuecomment-1652166703
We haven't touched this part of the code in a very long time (5+ years).
I recall there were some differences between JDKs, so it might be something to do with that.
Not specifically related to this, but in ClojureScript everytime we re-eval a fn from tooling we lose :line and :column. I created this some days ago https://ask.clojure.org/index.php/13085/clojurescript-doesnt-respect-provided-line-column-functions with a PR to the ClojureScript compiler, if we have that when redefining fns we should be able to keep that info