Yes. REPL sessions are local to each VS Code Window. So open each project in a separate window and you should be good.

By instance I meant window, sorry for the wrong phrasing.

Alright. Then no. 😃

Thanks

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 false.

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.

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. 😄).

Thanks :thumbsup:

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?

it worked two weeks ago 🙂

If we disable calva then there are no random changes happening

Very strange. Afaik we haven’t changed anything in Calva that should influence this. Can you try with an earlier version of LiveShare?

And please file an issue on Github so we can track this and collect more info and such.

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

Created an issue on Github now. (#1434)

Thanks!

@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.

Seems @UKFSJSM38 understands what the problem is. Thanks for the reporting! And don’t feel bad about not reporting @UGNFXV1FA. We’re all a bit too busy with other things at times!

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?

yeah, I think both combined that causes 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.

But I’ll do it tonight if no one else does by then

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

Releasing it now. 😃

What was the fix @U0ETXRFEW? Did the revert of @brandon.ringe’s PR fixed the live share issue?

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.

@UKFSJSM38 Did you release that change?

Calva version 2.0.231 was released and reverts the change that was likely the culprit. Can you verify that the issue is no longer present with Live Share, @U01TBJT2K5E and @U02GKV56HGC?

@brandon.ringe, yes we can test.

It works now

And we couldnt find any problems! Great job! 👍

Awesome. Great job, @brandon.ringe and @UKFSJSM38!

@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 I can release a clojure-lsp version

> 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.

no problem, If I have the time I can test it tonight

Is it something I can test? Just give me some info and I’ll do it now.

Just compile clojure-lsp from master and test it code actions are working again from calva dev branch

How do I test code actions? 😃 Is that the cmd+. thing?

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).

that was the issue we were trying to solve @U0ETXRFEW, thanks for the test

so it seems the issue keeps happening even if clojure-lsp is returning the edits on resolveCodeAction @brandon.ringe :thinking_face:

I can try to debug it later today if I have time

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

or cycle-privacy

I remember that only one was working, all the other ones not

OK, so now tried in a not-so-broken project where refactor->rename works. But no code actions want to do anything at all.

For me calva from dev + master clojure-lsp fixed the code actions issue

I'll test published calva now

Published calva works too :man-shrugging:

testing with latest clojure-lsp now, not master one

Yeah, it doesn't work with latest clojure-lsp, so what will fix it is indeed the next clojure-lsp release :) c/c @U0ETXRFEW @brandon.ringe

I should release this week

Awesome!

We tried to fix the find-definition inside deps and we actually broke the find definition to the deps 😂

it works on 2.0.229 but it doesn't on 2.0.229 or 2.0.230

Uh oh. Can you fix or revert?

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.233, 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.

Yeah, we should probably revert @UKFSJSM38 if you think that change was the cause, even if we don’t yet understand why.