Jack in to babashka repl without Clojure project

[didibus]

Sometimes I like to start ephemeral REPL sessions to play around with some idea and I don't need to persist files or have a project for it.

Right now you can cider-jack-in without a project or a file, in some empty clojure buffer, and Cider asks you if you want to run cider-jack-in without a project, which will start a Clojure REPL.

I was wondering if we could have the same functionality but for a bb repl as well?

[bbatsov]

That's just a matter of setting cider-jack-in-default to babashka. Perhaps we can also add option to prompt for the REPL type to use in such cases.

[didibus]

Having an option prompt would be great. I don't always want it to be Babashka, I'd want to pick which one.

[bbatsov]

Got it.

[vlnn]

Instead of having extra-configuration or extra user input every time you start cider-jack-in why not to create something like cider-jack-in-bb?

[bbatsov]

@vlnn That's a simple solution as well, but it's a slippery slope to have a jack-in command for every possible Clojure runtime. I'm not saying we won't do it, but I'm definitely cautious about this path.

[vlnn]

@bbatsov I agree, but making jack-in process longer and requiring user input is a bit worrying. Actually worrying me a lot! And it wouldn't be easy to pre-configure destination, as sometimes user may want to jack-in "unusual" environment. So it would be nice to have some kind of agreement here before writing the code (maybe temporary agreement!).

[didibus]

There could be a cider-jack-in-dialect or cider-jack-in-prompt (or whatever better name you can think of) that prompts for the dialect to jack-into. That way the standard jack-in can remain ClojureJVM. So there'd be at most one more jack-in for a multiple of runtimes.

[bbatsov]

@didibus Technically speaking there's no "standard" cider-jack-in anymore. It's just an alias for cider-jack-in-clj. I renamed it when we originally introduced support for ClojureScript.

But yeah - in general I was thinking of some command that prompts you for the backend to run, which might not even be a Clojure dialect down the road.

[ikappaki]

May I suggest a way to jack in to any nREPL without a project by still using cider-jack-in but specifying a numeric prefix argument, something like:

1. M-1 M-x cider-jack-in: jack in to clojure cli
2. M-2 M-x cider-jack-in: >> lein
3. M-3 M-x cider-jack-in: >> bb
4. M-4 M-x cider-jack-in: >> nbb
5. M-0 M-x cider-jack-in: ask user which of the above tools to jack in to
6. anything else reverts to cider-jack-in-clj as before for compatibility.

(Any new nREPL project tools can be assigned the next available numeric prefix argument)

or any variance of this, e.g. remove point 5, and cider-jack-in without a numeric prefix asks user for the nREPL type.

I have tested this to work fine in a prototype for the first four cases.

Thanks

[bbatsov]

@ikappaki I've always been a bit skeptical about prefix arguments as their discoverability is not exactly great. Obviously your suggestion will work, but I'm afraid few people will ever figure this out. I'm also wondering how will people remember which number corresponds to which tool.

Sometimes I wonder if it won't be best to just make the default command always ask you for the tool to use and the directory to use, and to attach the current behaviour (figure out stuff automatically) either a different command or some defcustom. The years have taught me that explicit is usually better than implicit and you use jack-in so rarely that pressing a few more keys in the process is probably not a big deal for most people.

[ikappaki]

Hi @bbatsov

@ikappaki I've always been a bit skeptical about prefix arguments as their discoverability is not exactly great. Obviously your suggestion will work, but I'm afraid few people will ever figure this out. I'm also wondering how will people remember which number corresponds to which tool.

I agree with the difficulty about discoverability since these won't be visible via tab completion. The number correspondence thought should be available in the fn's docstring (I assume here that people do know how to look into fns help).

Sometimes I wonder if it won't be best to just make the default command always ask you for the tool to use and the directory to use, and to attach the current behaviour (figure out stuff automatically) either a different command or some defcustom.

I think for this particular feature (just bring up an nREPL without the notion of a project dir), we only have to care about which tool to invoke, the start up dir then becomes irrelevant?

How about another suggestion that also asks the user about which tool to invoke

1. cider-jack-in behaves as is when a project file is present in the directory tree.
2. If no project file is found, then it asks the user which of the clojure cli, lean, bb or nbb to jack in to in no-project-file mode.
3. If users after some use find it annoying to always reply with the same answer, they could have a look at the fn doscstring and realize that e.g. they can use M-3 to invoke babashka, so they use that optional numeric prefix argument as a power tool short cut. Thus, they don't have to use the prefix arg until they have to, and these prefixes seem to me easy to remember once you repeated them a few times.

Please take these suggestions as food for thought to aid the discussion, rather than something I am vehemently pushing for, since I could be totally off.

The years have taught me that explicit is usually better than implicit and you use jack-in so rarely that pressing a few more keys in the process is probably not a big deal for most people.

Would you care to elaborate a bit more on this please?

Thanks

[bbatsov]

Would you care to elaborate a bit more on this please?

It's better for people to clearly understand how something is working instead of relying on assumptions that might to be true (e.g. they believe something works in one way internally, but it's actually different and so on). Supposedly implicit solutions have better UX, but that's true only if their behavior really matches one's expectations.

At any rate - I like your second suggestion better, so I'd be happy to review a PR implementing it.

We've been talking about cider-jack-in-clj, but I guess it'd be nice for cider-jack-in-cljs to work in the same manner (e.g. it'd be weird if one supports numeral arguments and the other doesn't).

[ikappaki]

Would you care to elaborate a bit more on this please?

It's better for people to clearly understand how something is working instead of relying on assumptions that might to be true (e.g. they believe something works in one way internally, but it's actually different and so on). Supposedly implicit solutions have better UX, but that's true only if their behavior really matches one's expectations.

To me, this translates to the docstring clearly describing the fn expected behavior, though not sure we are talking about the same area (UI vs fns) :)

At any rate - I like your second suggestion better, so I'd be happy to review a PR implementing it.

Raised #3300 for it.

We've been talking about cider-jack-in-clj, but I guess it'd be nice for cider-jack-in-cljs to work in the same manner (e.g. it'd be weird if one supports numeral arguments and the other doesn't).

I've turned the cider-jack-in alias to a fn that maintain the current behaviour but added more functionality to it, thus avoided touching the lower -clj/cljs variants.