Support the most common interactions without the need for extra middleware

[bbatsov]

Is your feature request related to a problem? Please describe.

Some people are always frustrated that CIDER requires some additional setup (namely the need for cider-nrepl) and would prefer if they had a limited subset of functionality, but everything worked out of the box.

I resisted this idea in the past, but now I've come to realize that my ideological purity is not necessarily the right thing. There are also some other practical benefits from a more flexible approach - namely you could connect to any random nREPL server and get a bit more than just basic evaluation.

Describe the solution you'd like

We'd simply put some fallback for cider-nrepl powered commands (when possible) that's simple evaluation of Clojure code. Ideally we'd have to come up with code that's bundled with Clojure but we can also add some checks for common libraries on the classpath (e.g. orchard, compliment, etc).

I think the most important things we should aim to support with this eval fallback are:

• completion
• jump to definition
• doc
• eldoc
• running tests

Note: all such evaluations should happen in the tooling session, so their results won't mess up *1, *2, etc.

Describe alternatives you've considered

There are no real alternatives to this (at least I can't think of any), and the eval approach will become even more feasible when we implement sideloading in nREPL.

Additional context

CIDER used to have such a fallback mechanism prior to version 0.8, so we can restore a bit of functionality from there. I know @arichiardi will be happy about this direction. :-)

[bbatsov]

My bad. They were removed in 0.7, but here you can see how things used to look before -

cider/cider-interaction.el

Line 563 in fd14211

(defun cider--jump-to-def-eval-fn (var)

To avoid having to load code in such a horrible manner I'm thinking that we can just ship a few .clj files with CIDER and load those on startup or something along those lines. Simple code can be embedded directly though.

[arichiardi]

Oh oh so so happy 😄

I guess you also mean things like apropos, dir, ... ?

[bbatsov]

Yeah, potentially. We'll see what makes sense and what doesn't. I don't want to go overboard with this and for some things the UI will likely be different (e.g. just dumping stuff in the REPL).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[vemv]

clojure-lsp might be considered to have filled this niche by now.

It's not uncommon for users use both libraries, mixing and matching features.

In face of that, perhaps any work in the suggested direction could be considered redundant?

[bbatsov]

4/5 items are done even now (I've added more functionality to nREPL to account for this). We're just missing a simple eval-based test-runner. (no bells and whistles, just some output in REPL) That's something orthogonal to the use of LSP IMO.

[bbatsov]

See https://metaredux.com/posts/2020/06/15/nrepl-0-8-evolving-the-protocol.html

[vemv]

Got it, thanks. I didn't realise the fallback was to nrepl, not to some sort of offline op.

Evaluating (clojure.test/run-tests), (clojure.test/run-all-tests) etc as a fallback in cider.el when the test ops aren't available might suffice.

WDYT?

As you say, all output would be repl-based, with no UI whatsoever.

[bbatsov]

Yeah, that's exactly what I had in mind. And we were doing in the legacy clojure-test-mode project (see https://github.com/clojure-emacs/clojure-mode/blob/92f813c4fdd6f124a79f22a1848e15e22e0714a6/clojure-test-mode.el) that was replaced by the test middleware.