Is it possible to have the LSP not apply to folders outside its' source tree? e.g., with a project structure like so:
/proj
/sub-proj
/.clj-kondo/config.edn
/sub-proj-2
/.clj-kondo/config.edn
I have to start 2 LSPs (which is fine, imo), but, both LSPs apply to both projects, so I actually see errors while editing files in sub-proj-2 because sub-proj isn't configured for sub-proj-2.The best for this case is start a single LSP at proj , this is how clojure-lsp project itself works, it's a mono-repo with 2 sub projects lib and cli inside.
So you have some ways to configure that via a deps.edn with :dev alias pointing to the paths inside the subprojects or configure via .lsp/config.edn in the root the sourcepaths
that's awesome, thanks much! It took a little fiddling but that seems to work great
I need to write in clojure-lsp docs a page about best/recommended way to work in a mono-repo with clojure-lsp
hey š is it possible to configure different keyboard shortcuts for different REPL connect sequences? for example when I connect to a repl connect sequence X, I want cmd+r to do something, but if I connect to the repl connect sequence Y, the same command does another thing, is it possible?
Not really possible. But we can make it easy to do this. Please file an issue about it.
https://github.com/BetterThanTomorrow/calva/issues/2940 thanks @pez gratitude
I updated Calva today. My previously working custom connect sequence now gives an error:
Initialized shadow-cljs runtime status notifications
Creating cljs repl session...
session did not shadow-remote-initConnecting cljs repl: fulcro-rad...
Starting cljs repl for: fulcro-rad...
My custom connect sequence that worked before the upgrade:
{
"name": "fulcro-rad",
"projectType": "deps.edn",
"cljsType": "shadow-cljs",
"afterCLJReplJackInCode": "(require 'development :reload) (in-ns 'development) (start)",
"menuSelections": {
"cljAliases": ["dev", "cljs", "test"],
"cljsLaunchBuilds": [":main"],
"cljsDefaultBuild": ":main"
}
My app appears to load like normal but the shadow-cljs dashboard never loads, and the websocket connection fails:
The connection to was interrupted while the page was loading.
FYI: https://clojurians.slack.com/archives/CBE668G4R/p1758717681240359 For shadow versions < 3.2.1 this should now be a no-op as pertains to the repl server, so should really not interfere. It also means that the support for reactive runtime connection/disconnection detection is removed for your project going from 531->533. I simply couldnāt figure out how to not risk creating a race condition when dealing with prior shadow-cljs versions.
I even tried using the built in deps.edn + shadow-cljs and my app starts, the cljs dashboard loads, but the websocket still errors.
I upgraded everything to latest, clojure, clojurescript, shadow-cljs, everything is latest. I am seeing this now about piggieback:
Process shell is: true
ā”ļø Starting the REPL ā”ļø using the below command line:
(cd /home/mwhitford/src/gailish; clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"1.3.1"},cider/cider-nrepl {:mvn/version,"0.55.4"}}}' -M:cljs:dev:dev -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware shadow.cljs.devtools.server.nrepl/middleware]")
Syntax error compiling at (shadow/cljs/devtools/server/nrepl.clj:1:1).
namespace 'cider.piggieback' not found
Full report at:
/tmp/clojure-18284559548931529269.edn
Jack-in process exited. Exit code: 1
I even tried adding cider/piggieback to my deps.edn with latest version.I think I have a solution, I changed the afterCLJReplJackInCode to this and it appears to have solved the error:
"afterCLJReplJackInCode": "((requiring-resolve 'shadow.cljs.devtools.server/start!)) (require 'development :reload) (in-ns 'development) (start)"The latest change is targeting shadow-cljs, so this regression is very likely about that change. But very strange⦠Latest shadow is 3.2.1, I take it?
I did try to upgrade shadow-cljs to 3.2.1 but fulcro doesn't like it. I am back to shadow-cljs 2.28.22 and that added code for clj jack-in.
Thanks. That would mean youāre on clojurescript 1.11 something too? And the version of Calva you were using⦠2.0.530? Seems your post is a bit to quick on the release of 531. 530 and 531 should behave the same with shadow 2.28.22 , but for my bug hunting itās still good to know.
That output suggests it was 530ā¦
Initialized shadow-cljs runtime status notifications
Creating cljs repl session...
session did not shadow-remote-initConnecting cljs repl: fulcro-rad...
Starting cljs repl for: fulcro-rad...I have clojurescript at 1.12.35, with closure-compiler-unshaded at v20240317
Ah, I had the wrong idea about cljs compatibility with shadow 2. Can you try with Calva 531 and your original clj start code?
I had calva running for probably two weeks or so since I last updated and restarted, but I did a reboot today and calva was for sure updated when I ran vscode after the reboot.
Yeah. defaults are that extensions update automatically, I think.
All this shadow stuff is the last few days.
You have to let it restart to update though which I put off for the past couple weeks. been running my AI chatbot out of the calva repl for that long and didn't want to take it offline...
Thatās very cool!
Iāll try a thing. For how long are you going to stay online?
I'm about to go to bed it's 10.30pm for me. I will be available tomorrow, and can play with it more then.
Sleep tight, thanks for the report, Iāll see if I can repro in any way.
Can you confirm which Calva version you were using?
It makes me wonder if there is a race condition on shadow start that the requiring-resolve is adding just enough time to either win or lose the race.
Thatās why the Calva version is important. We send the shadow remote init messages in a different place between 530 and 531, so the race should look different.
Right now I am running 531, that is the one that showed the errors earlier afaik. I rebooted, tried to jack-in and got those errors, and that is what I pasted into the start of this thread.
It was released two minutes before your post here, so I wonderā¦
Ok so probably it was 530 then and as I was troubleshooting it updated again, I definitely killed the editor multiple times so it could have upgraded to 531 from 530 behind my back.
so maybe the fix I put in my jack-in code just coincided with the upgrade to 531.
Yeah. So if you try with your old after connect code now. Same error?
I will remove it and try again give me minute.
Yeah that must have been it 530 gave that error in my mucking about trying to troubleshoot it must have upgraded to 531 which fixed it.
I removed the requiring-resolve and the run of the shadow-cljs start function and it's still working on calva 531.
Thanks. That means it is very probably a race condition that I need to figure outā¦.
I just blew out everything and re built it all from scratch without the extra jackincode and it's all working great on 531. Even reverted the git repo to the version it was running this morning before the issue. I think that isolates it to an issue with 530 that 531 fixed for me, and it was just weird timing for me between those versions.
Itās good for me that you managed to reveal the problem with a margin of a minute or so. š
I think I rebooted 90 minutes or so before that post and between trying to see if I messed something up and creating the post was more than just a few minutes.
A real life race condition. Nifty.
Haha!
I created an issue for it. Will chill a bit with trying to release a fix it, in case it is already fixed. But I will try to repro and investigate to understand whatās going on. https://github.com/BetterThanTomorrow/calva/issues/2935
I am getting command 'paredit.deleteBackward' not found when opening project folder in WSL via vscode remote wsl connection. Opening normal windows folder does not have this issue. how do I troubleshoot this? I rarely use calva with wsl lately so I don't know if this is a new issue or not
ah right, I forgot that vscode have some browser debugging capabilities. and from the log I found the culprit: a paredit extension when I was tinkering with fennel. uninstalling them solve the problem! thank you for your help!
Very strange. I really have no idea why this would happen. Can you check the console log (VS Code dev tools from help menu), and see if something is reported about Calva having issues. Thereās quite a bit of noise and false positives there, but you could compare to non-WSL, and hopefully see something.