@lspector , it could be that the cljs repl fails to start in that cljs-quil repl. I have noticed that recently there seems to have changed something in regards to piggieback dependencies. This is why i prefer long beautiful command lines. They are more flexible than configuration buried in projects. But I'll try it myself and fix that project if I understand what is missing.

@somedude314 , if you are connected to a cljs project, Calva creates two repl connections for the editors to use. One for clj files and one for cljs files. So if you are editing a cljs file and do inline evals, it will be the cljs repl that handles the evaluation for you. And for clj files, the clj repl. Cljc files default to clj, but you can toggle it to cljs with a button in the status bar.

Calva also creates two vscode terminals and connect one to the clj repl server and the other to the cljs server. You select which one to use with vscode's terminal selector. (And for the “evaluate in repl terminal” commands calva uses the same logic as for the inline evaluations.)

@lspector, actually, the piggieback dependecies are correct in the project. Something else is going on. You might notice at the terminal prompt where you started the repl and did (fighwheel start) everything compiles and the app starts, but there is never any cljs-repl prompt appearing. So, even w/o Calva in the picture, something has changed. Totally strange, and you and I are both witnesses that this worked just a week ago. I'll try to figure it out, but right now I am just totally clueless.

@lspector: OK, so I didn't figure it out, but I found a fix that works on my machine. If I bump the figwheel-sidecar dependency up to 0.5.19-SNAPSHOT the cljs-repl starts and Calva can connect to it. I can't for the life of me understand why that wasn't needed a week ago, but, hey, at least now we get a cljs repl. I have pushed the change to the repo, so please pull and see if it works out there as well.

About those example code lines to practice how to inline eval in Calva that I put in core.cljs of that project. I used them the other day when my son asked about the unit circle. He knows that sin(PI/6) is 1/2, so he started laughing at (Math/sin (/ Math/PI 6)) => 0.49999999999999994. We then tried it in CLJ and he relaxed when it answered correctly. 😃

Hmmm, OK, so now I think I know what happened...

Yep. I was using a SNAPSHOT dependency on cider-nrepl, which then moved. Now fixed that in the repo, @lspector, so it should stay working now. Totally sorry for the inconvenience I caused.

So, a colleague is exploring Clojure and Calva, which is great, we found a little stumbling block:

He started by asking:

> Clojurians, is there a shortcut in Calva to say (in-ns '...) or do I have to type it out myself?

and followed up with

> I.e. when evaluating a form in the REPL, I would like it to infer what namespace I’m in from the file

Turns out he’d found the wrong hammer:

Calva has two quite similar commands:

Yeah, I've renamed them slightly in Calva 2.

He was using Evaluate current form (or selection) in REPL terminal where he should have used Evaluate current top level form

There is a command for (in ns), though.

I guess my point is, (and I see you’ve thought about this too), is that Evaluate current top level form should be renamed to Calva: evaluate-DWIM or some such 🙂

DWIM?

Do What I Mean 🙂

Haha, yeah. I'd love that too.

Just one data point though, and hopefully some food for thought.

So these are the names I use in Calva 2.

I think one of the things that threw him off is the wording top level form

Also, the commands for sending forms to the REPL will evaluate them in the namespace of the file, regardless of what namespace the REPL window is using.

In his mental model, the top level is the ns

Ah, interesting.

I guess that’s not for you to solve, but it’s an observation none the less

paredit.js uses the name evalDefn instead of top level. That confused me, so I changed it.

I’ve never looked at the name of these things when I use Cider, as I’ve always just used the keybindings.

C-c C-c runs the command cider-eval-defun-at-point (found in
cider-mode-map), which is an interactive compiled Lisp function in
'cider-eval.el'.

In Calva the evaluation of top level forms take a front seat when it comes to key bindings.

That defn again!

Totally strange name.

Which may or may not be precise, as I haven’t seen what happens if I do a C-c C-c on a top-level let-binding 🙂

Hang on 🙂

Yup, the name is lying 🙂

it should be renamed to cider-eval-top-level-form-at-point.

^ @bozhidar 😄 ^

I wonder if @bozhidar will accept a PR :thinking_face:

Haha, two spammers

While I agree that some variation of eval-top-level-form is technically more correct, eval-current-defn might make more sense to new-commers

or even redefine-current-defn

Also I think CIDER does not consider comment forms creating a new top level, by default. Which is a bit strange to me.

I think it risks causing confusion that redefine-current-defn would be the thing to use for evaluating the ns form and whatever top level form. It's not easy to decide about names, always someone will be confused. But certainly, something should be done to ease the path for newcomers.

It doesn't appear to highlight #(...) as comments. Is that something I can enable, or is it not implemented yet?

Also not seeing functions listed in the outline panel. Is that not implemented yet?

I'm just trying it out (been using Emacs). It looks promising so far.

None of that is implemented yet. But you are reminding me about my branch which tries to fix that #_ highlighting. I spent a lot of time on it and I think I might be close even. But, not close enough for release. I should pick it up again: https://github.com/BetterThanTomorrow/calva/blob/wip/grammar-comment-expression/calva/calva-fmt/atom-language-clojure/spec/clojure-spec.coffee

About the outline, I think @alexander.minolta started to look at the symbols listing, which might be related.

I'm guessing you have to parse Clojure yourself and the Clojure compiler gives you no help, the way some compilers have a "language server" or something like that?

Trying out the new calva clojure4vscode-2.0.0-SNAPSHOT.vsix

Is there a usage guide that explains what I should do to get the happy path? What’s the relation between jackin and connect?

Should I jackin AND connect or are they to be used mutually exclusive?

Very good question! I must make that relationship clearer. The answer is that jack-in will also connect you.

hmm does that mean I should also open a repl (like in a terminal window lein repl) prior to connect/jackin?

Somebody I trust a lot suggested to find another name than Jack-in. What it really does is start the repl server for you, correctly configured for Calva, and then connect. Thing is i am very find of jack-in. It sounds so cool! Maybe I should name Connect a bit more clearly...

How about: * open a local repl (jackin) * connect to a remote repl (connect)

If Jack-in works for you, then no need to lein repl anything. But if it's not (and right now it might not work for you) then you need to start the repl yourself and then connect.

Connecting to a remote might become most common use case for connect, but it is not exclusively for that...

Maybe: 1. Start a REPL and connect (jack-in). 2. Connect to a running REPL.

(Calva has a bit poor support for remote repls right now, so it probably shouldn't be promoted.)

I used the remote repl with some success debugging a remote onyx cluster 🙂

I found some issues with discoverability when stumbling on blocks using macros in general

I think we need some mapping of file paths.

Though you might already be aware of it, if not I should probably try to make a minimal reproducable case

Oh, please do and file it as an issue.

or perhaps the new beta is expected to fix some of those?

I was completely unaware until now. 😎

ok

> That defn again!

The naming is weird on the outside, but defun is the Emacs Lisp terminology for a top-level form in most languages.

🙂

@slipset @pez ^^

Not sure who decided this was a good idea, but it’s such a strong convention at this point, that it’s extremely unlike it would ever be changed.

:) I don’t really think I was serious in suggesting a change of name.

I suspected some age-old reason. 😎

It’s really hard to let go of the past. 😉

It is. And > The naming is weird on the outside is telling. Calva is sort of there for people coming from the outside. Fortunately vscode is very good at surfacing functionality based on searching. So I need only include defun in the command names/descriptions and the insiders will be able to find them. Doing that right now.

Like so:

That’s super nice!

I would, however, and feel free to ignore, choose defn over defun, as defn is what it’s called in Clojure.

I think defun avoids it being fully confused with defn, and that that is a good thing.

In new snapshots, where does the standard output of the jacked in app end up going (aka (println))