This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (36)
- # aleph (1)
- # announcements (7)
- # aws (4)
- # babashka (9)
- # beginners (61)
- # calva (79)
- # cider (19)
- # clojure (48)
- # clojure-austin (1)
- # clojure-australia (2)
- # clojure-czech (2)
- # clojure-europe (46)
- # clojure-france (8)
- # clojure-nl (19)
- # clojure-uk (4)
- # clojuredesign-podcast (14)
- # core-logic (42)
- # data-science (3)
- # datalevin (8)
- # datomic (76)
- # events (1)
- # figwheel-main (9)
- # fulcro (6)
- # helix (1)
- # holy-lambda (1)
- # honeysql (2)
- # jobs (2)
- # jobs-discuss (17)
- # leiningen (5)
- # lsp (87)
- # minecraft (11)
- # nextjournal (4)
- # off-topic (17)
- # practicalli (1)
- # reagent (22)
- # reitit (8)
- # releases (3)
- # rum (2)
- # shadow-cljs (18)
- # sql (11)
- # tools-build (5)
- # tools-deps (9)
- # xtdb (20)
Yes. REPL sessions are local to each VS Code Window. So open each project in a separate window and you should be good.
Calva currently has four ways of running tests:
• Run All Tests (No evaluation, runs all tests)
• Run Tests for Current Namespace (Evaluates the current file, finds a matching
-test file if one exists, runs tests in both files).
• Run Current Test (Evaluates the current file, finds the var under the cursor, and tests that var)
• Run Failing Tests Again (Evaluates current file, calls the
restest op, https://github.com/clojure-emacs/cider-nrepl/issues/741)
When we add test explorer, there will be some more ways to run tests:
You will be able to run all tests, or chose some test(s) to run from the tree-view. This allow you to run tests for a namespace or var.
What should the behaviour be for evaluating files in these cases? Let’s say someone’s editor is in
foo) and they click on the “Run Test” button for namespace
bar. What should be evaluated?
For a namespace it makes sense that the file is loaded, I think. (Or evaluate the whole file, tbh I am not completely sure what the difference is in results.)
It could also be argued that nothing should be evaluated. And that whatever is loaded in the REPL is what is run.
So, maybe a setting, Load current namespace and test namespace when running tests defaulting to
The current behaviour of
Run Current Test is nice IMO - with my cursor on a form I can press
^⌥CT to run the test, regardless of the state of the REPL
I’d like our behaviour to be the least surprising option. I don’t know what that is though.
Yes, running the test regardless of the state of the REPL makes sense. The question is what to run. 😃 Today we load the file for all run test commands. Which, iirc means we run whatever is saved on disk. I think that could surprise some people and be what others expect. I’m usually not one to suggest settings, but here I wonder if it is not the best way. Then at least someone who is surprised by the defaults can influence the behaviour.
❓ is there a way to “save” the Jack In command for a workspace? Currently, ever time I Jack In, I have to flip through the options to choose the REPL type, and then launch. I’d like to save this setting per-workspace so that I can Jack In with a single command, without a prompt.
You can get it down to one prompt using a custom REPL command sequence: https://calva.io/connect-sequences/ (And if you squint you can regard
ctrl+alt+c ctrl+alt+j enter as a single keyboard shortcut chord. 😄).
Hi, anyone having issues with calva together with the Live Share extension? Use Liveshare v1.0.5196 and Calva
v2.0.229. Files are edited randomly, adding brackets and adding new functions.
here is two short clips of it. Only the cursor position was changed. No other keys were pressed
Awful! Have you been using them together before and it has stopped working now, or is it the first try? I’m not a LiveShare user, maybe @UGNFXV1FA has some idea what could be going on?
Very strange. Afaik we haven’t changed anything in Calva that should influence this. Can you try with an earlier version of LiveShare?
If you file the issue from VS Code (the Help menu) it will attach some system info that could be useful.
Problem seems to be on version 2.0.226 It works fine on 225 even with different versions of live share
@U02GKV56HGC, can you add that info to the issue? https://github.com/BetterThanTomorrow/calva/issues/1434
Yeah very awful indeed. I've also experienced this the last couple of weeks, but I've been so busy that I didn't get around to reporting it 😞 My hunch is this is a side-effect of some other change, but who knows. Like @U0ETXRFEW said, there were no changes to the live share part itself AFAIK.
Since latest clojure-lsp already return edits on code-actions, my suggestion is revert the PR @brandon.ringe opened to fix code actions as this is not needed anymore, right @brandon.ringe? and that should fix the issue
Do you think the change I made alone, without the edits update on clojure-lsp caused the issue? Or is it both of them combined that’s causing the issue?
https://github.com/BetterThanTomorrow/calva/pull/1400 Here’s the PR. Anyone, feel free to revert it, as I’m in the early part of my work day and won’t be getting to it for several hours.
If the issue is only affecting live shares, I think the issue is not that big, so I'd go with a safer approach of testing with caution
No, I’m sorry for spreading false information. Not releasing any fix for this. I’ll let you who understand the issue better sort that out.
no problem, I'm just afraid of reverting that PR and introducing again the "Code actions not working" issue 😅 , I think bringe will confirm that for us later
> Since latest clojure-lsp already return edits on code-actions
This doesn’t seem to be the case. With latest (`2021.12.01-12.28.16`), codeAction/resolve requests still return a
command and not an edit.
@brandon.ringe you are right, I didn't release that change yet https://github.com/clojure-lsp/clojure-lsp/blob/master/CHANGELOG.md#unreleased So, we are back to code actions not working but now we don't have this liveshare issue, right?
@brandon.ringe can you test later if the clojure-lsp master fixes the code action not working on calva?
> So, we are back to code actions not working but now we don’t have this liveshare issue, right? Correct, but I’d rather a convenience feature not work than an issue that makes Calva unusable with Live Share, for now. > can you test later if the clojure-lsp master fixes the code action not working on calva? I might not have time to test it today, sorry. If I do, I will, but I’m pretty busy.
Just compile clojure-lsp from master and test it code actions are working again from calva dev branch
I’ll have to test it later. Family needs food now. But I’ll do it later tonight unless someone else has beaten me to it.
So, I am not a frequent user of code actions, and I am not sure what to expect. Take this report for what it is. I am using Calva from latest
dev and clojure-lsp from
master and I don’t think it works. I think I could get cycle privacy to do its thing briefly, but then that stopped working as well. Mostly, if I have a saved file, any code action I try, leaves the file in saved mode (so not “dirtied” as it would be if something was edited).
so it seems the issue keeps happening even if clojure-lsp is returning the edits on resolveCodeAction @brandon.ringe :thinking_face:
I might have tried in a project where things are not properly configured. I notice that not even refactor->rename works. Let me try in a more reasonable project…
yeah, all code actions should work, a easy test is try
cycle to map on a list or set or vector
OK, so now tried in a not-so-broken project where refactor->rename works. But no code actions want to do anything at all.
I noticed that on version
2.0.229 the find definition to external deps stoped working @brandon.ringe 😅
We tried to fix the find-definition inside deps and we actually broke the find definition to the deps 😂
I'm trying to understand what happened and if it's easy to fix, but I'm not finding anything, probably I'll do the revert :/
I didn't find anything, for some reason only the first
textDocument/definition request is done with success and the others not, maybe we should revert and do a fix release?
I've just tried
2.0.227 and I can't even f12 to
clojure.string. I'm pretty sure I was able to jump to definitions easily before today.