Not currently. There’s an issue about it, I think. Maybe you can describe your use case a bit there?

That’s not pretty! Please file an issue. And consider providing a PR too. 😃

Ok, I’ll make an issue first!

https://github.com/BetterThanTomorrow/calva/issues/2141

I've brought this up before, but never filed an issue. That and I couldn't find a reliable way to clear/hide inline failure reporting when it was either stale or interfering with my ability to edit relevant code. My take from pez's comments at the time was that the VS Code test runner is legacy from the early days of Calva. It is not getting attention anymore because pez doesn't use it anymore. Seemed easiest to me to just move on and pretend it's not there. Somehow or other, I guess I must have disabled the feature? (Probably just a settings toggle.) And then I moved toward other test runners that work in the repl and/or the terminal.

The test explorer integration is pretty new, actually. Unfortunately the contributor is no longer doing Clojure. But that does not mean we are not maintaining it. Quite the opposite, and I wish you wouldn’t imply things like that, @U90R0EPHA. It is a big feature, though, with a lot of integration points. The API in VS Code is, as is very common, not built with a dynamic environment like Clojure’s in mind. It makes it hard to create a clean integration.

Did not mean to offend. Just sharing my interpretation of and response to previous discussion. I knew you were already involved in this conversation, and could substantiate or refute my perspective.

Yeah, I guess I should be scrutinizing what I have said about it that gives the impression that we don’t give attention to the test runner things. No offense taken!

Welcome to Calva! You could probably find some theme that does this for you. There’s some info here about how to customize themes. https://code.visualstudio.com/docs/getstarted/themes I see an example there for making declarations bold.

not sure how I missed this in the docs. thanks!

i love that there's intellij themes for vscode and vice versa

I guess people like to feel at home. 😃

My favourite theme is Github Dark Default. It is very complete and pleasant.

There is a command for loading/evaluating the current file, if that’s what you mean. Search in the command palette and you will find it. Nothing in comment forms is executed when you evaluate the file. I can recommend looking at the source for the comment macro.

Ok, my bad I was pretty sure it was evaulating comment macros as rich comments.

Interpretation error

Are you a beginner to Clojure, @U0111PVCS8P? This interpretation of Rich Comments is interesting.

The way you are using the comment forms is exactly what is meant by Rich Comments, actually. They have their name from Rich Hickey, who is known to use them like that too, plus that there often is riches inside them.

Calva doesn't need to do anything to avoid evaluating your code inside a rich comment. The comment form is actually evaluated. But it is a macro. And what that macro does is intentionally ignore the body (your "commented" code) and just evaluate to nil.

I’m not a beginner to Clojure, I’m just mixing things up, sorry. I just know calva can eval comment forms as do forms, I thought it was doing that when I used “eval whole file”

I also was misinterpreting “rich comments”. For some reason I thought rich comments was about the IDE adding features to comment, just like the “eval as do” calva command

I see. Of course using fancy terms like Rich Comment Forms is prone to relay some other things than intended. It has just never occurred to me. Thanks for elaborating. Interesting stuff words and such! 😃

"I just know calva can eval comment forms as do forms" -- that's not quite right (is it @U0ETXRFEW?) -- you can evaluate an individual form inside (comment ..) but if you evaluate the whole (comment ..) none of the forms inside are evaluated (and you just get nil back from the comment macro). I wonder how we can talk about this more clearly... I recently overhauled part of https://clojure-doc.org and mentioned Rich Comment Forms: https://clojure-doc.org/articles/tutorials/getting_started_cli/#interactive-development -- I'd be interested in your feedback on whether that's equally confusing?

(I've surfaced that Q in #C02CPM2R1KK because I'd like general feedback, not just Calva-specific feedback)

I think it has been suggested to be able to evaluate the whole comment content as a do form. But I don’t recall implementing it…

Rich comments are a language feature, rather than editor feature. But you do need an editor/IDE to take full advantage of them. The beauty is that an editor can offer linting, highlight, evaluation, etc. without needing to even know the "comment"ed code is not going to run by default. And we don't need super-complex parsing to try and and make imperfect guesses of what is or isn't code, like we would if it was a normal comment.

Yes, it’s a new warning. We got a lot of support questions about things not working in Calva because the basic dependencies were not met. You should follow the advice in there and fix it. Calva has a command for copying out the command line it would use to start the REPL. You can use that and compare with the command line you use.

FWIW, we get this warning connecting Calva to nREPL servers running on staging and production -- because we deliberately choose not to have the CIDER middleware present in remote processes -- but I haven't seen anything specific "not work" yet without CIDER for a workflow that interacts with remote servers. I add that caveat because we're not doing anything with source code or tests -- just straightforward evaluation of (local) code into the (remote) process, with display into Portal (using VS Code's Simple Browser, connecting to a Portal server running inside the remote process).

@U0ETXRFEW I think I've asked this before but it would be great if you could add a section to the Calva docs that explicitly lists what "won't work" if the CIDER middleware is omitted -- is that practical or is it too tangled a web to be able to tell for sure what functionality would break?

Yes, we should document that.

https://github.com/BetterThanTomorrow/calva/issues/2143