This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-03
Channels
- # announcements (1)
- # babashka (31)
- # babashka-sci-dev (53)
- # beginners (34)
- # calva (54)
- # cider (15)
- # clj-kondo (9)
- # clojure (115)
- # clojure-dev (19)
- # clojure-europe (21)
- # clojure-nl (1)
- # clojure-norway (78)
- # clojurescript (10)
- # clr (9)
- # community-development (9)
- # core-async (24)
- # cursive (18)
- # datomic (59)
- # emacs (43)
- # figwheel-main (2)
- # fulcro (4)
- # graphql (4)
- # malli (7)
- # meander (12)
- # nbb (14)
- # off-topic (22)
- # polylith (9)
- # re-frame (5)
- # reitit (3)
- # releases (1)
- # shadow-cljs (36)
- # sql (1)
- # tools-build (23)
- # xtdb (13)
Hey I know this is for Calva not VSCode but, does anyone have any ideas for debugging a very frustrating appearance of a 4-8 second wait for the editor to react to a keypress? I recall Emacs had a debug mode and I’m wondering if there’s something similar (but my google fu is failing me)
Just updated to the latest Calva -- v2.0.330 -- and after the reload window command, LSP did not start back up. After trying a few things, it seems that if you have certain types of editor open and focused when you do the reload, LSP does not start. If you have a Clojure editor open, it does start after a reload. I had a commit history editor open -- I had opened a .sh
file and then in the Explorer, expanded the Timeline and selected a recent commit. I haven't yet tried other Calva versions to see whether this is just an edge case of behavior that I've never noticed before or whether it's a regression...?
Thanks for reporting! Are you sure LSP is not running? I think the indicator might not tell with files/editors which are not part of a project.
If I switch back to a Clojure file, the indicator still shows not running and there's no syntax coloring from LSP, just the VS Code default.
Ah, and if I wait a while, it seems to start and then the indicator shows it is running and syntax coloring reappears. Interesting.
It takes about 10-15 seconds after switching to a Clojure file after the reload (with the commit history editor having focus). Let me try a few more experiments...
OK, looks like it is just a display/indicator issue. On the project at work, LSP takes a while to start up -- but if I start VS Code/Calva with a Clojure editor having focus, I see the spinning progress indicator on LSP. If I start VS Code/Calva with that commit history having focus, there's no progress indicator for LSP, and if I switch to a Clojure file it shows inactive (not in-progress/starting). However, if I leave the commit history editor open and focused, the solid LSP running indicator does appear after that startup time.
So "it's fine!" and I suspect I've just never noticed before... but it is a bit of a UX issue (if LSP is starting in background, it should probably show the spinning indicator, regardless of what editor has focus?).
I guess it's just weirdness that it doesn't show the spinning startup indicator if I switch from non-Clojure to Clojure editor before it has finished starting...
(probably not worth fixing)
I think it is worth fixing. It was something we discussed in the PR as a potential issue. The challenge here is that there’s this concept of multiple lsp servers, and the indicator is used for the current server, based on the file that is opened.
Ah, so prior to this work, the indicator likely showed up even when a non-Clojure file was open? And the situation at work is that there's only one LSP server because there's only one project in the workspace.
Airity checking seems to be off. v2.0.330 or v2.0.324. I get an error saying it expects two arguments but it only received one. Running it in a repl is fine. Not sure if Schema.core is confusing it. See attached screenshots in theread
If not (and restarting clojure-lsp was already done by you switching Calva versions), then maybe Schema is confusing it. If you can provide a small repro that would help.
Unfortunately the company won’t allow me to do that. I noticed that on the latest version the lsp server doesn’t start, I have to manually click to start it, then pick a root module. Is that the new normal? In the old version of Calva, the lsp would automatically kick off on start up
But the error is also present in the older version, so not sure.
The other weird behavior is that the “Organize Imports” doesn’t show up in the command palette on the latest version.
> Unfortunately the company won’t allow me to do that. Maybe you can reproduce the issue in a small, separate project and share that? > I noticed that on the latest version the lsp server doesn’t start, I have to manually click to start it, then pick a root module. Is that the new normal? I think at least if it’s not a monorepo, clojure-lsp should start automatically. If it doesn’t, there may be a bug. CC @U0ETXRFEW @U04HKE0BTC5 > The other weird behavior is that the “Organize Imports” doesn’t show up in the command palette on the latest version. Are you referring to the command “clojure-lsp Refactor: Clean NS Form”? And if so, does it not show up even when clojure-lsp is started and when you have a clojure file open?
Regarding the last thing, Yes, that’s correct. It doesn’t show up even with lsp running and a clj file selected.
@U9A1RLFNV Currently traveling back home - will take a look at this and the other github issues once I am back tomorrow.
Thanks @U04HKE0BTC5 ❤️
@U03EEEB90DV Can you create an issue for the “clean ns” command not showing up?
Also can you check if this issue is related to your non-starting issue? https://github.com/BetterThanTomorrow/calva/issues/2065
Thanks @U9A1RLFNV, it does look related. I’ll do that. Create an issue, and update the other one if I have any additional info
> The other weird behavior is that the “Organize Imports” doesn’t show up in the command palette on the latest version. This I can’t reproduce. This command should always be there independently of the LSP server running - it should however fail to execute if there is no lsp running. Not sure why the command isn’t there at all for you. Maybe something unique with the project structure?
I'm also trying to debug some issues with this recent multi-root workspace LSP change. It seems this new concept of multiple LSP servers is not working with our monorepo setup, could use some advice.
Right now we have a monorepo with an auto-generated deps.edn
containing all our dependencies and project paths in the root. My multi-root workspace is configured with the repo root directory as the first workspace folder, so previously Calva would start one LSP server for the monorepo and this enabled LSP features across the repo, including individual subfolders that I mapped to other workspace folders. That was working great.
Now I start up Calva and all of the sudden I'm running dozens of LSP processes since I have a number of Clojure projects in my multi-root workspace. I tried changing my config to "calva.enableClojureLspOnStart": "when-file-opened-use-furthest-project"
, which seems to be closest to the previous behavior, though the down side is the LSP server no longer starts up when I open my workspace like before.
Though the main issue is that some features seem broken now regardless of which enableClojureLspOnStart mode I'm using if I don't have a dedicated LSP server running for that specific project. I don't have an exhaustive list, but go-to-definition and auto ns imports do not work anymore, Calva prompts me to start a new LSP server, but I do already have the repo root LSP server running with all of these projects on the classpath.
I do appreciate all the work that has gone into improving Calva and LSP integration over the years, but I do wish major changes like this could be introduced in more backward-compatible way. It's really disruptive to open up your IDE one day and find that you need to debug why everything broke all of the sudden. In this case, I think enableClojureLspOnStart
should have had a default setting that had the same behavior as before, and have the new behavior be optional.
I can see that this new behavior is probably an improvement for most users not using a monorepo, I'm just trying to figure out how I can restore my workflow (aside from rolling back the Calva version).
We use a monorepo -- 135k lines in about 160 component subprojects, each with their own deps.edn
.
I guess my question would be: why do you have both the root folder and multiple subfolders all as projects in your workspace? I just have the workspace root, run a REPL for that deps.edn
for development, and everything "just works".
(I do agree that having the new behavior be "opt-in" and having the default be to just start one LSP server in the first workspace folder as before would probably make this less painful for people)
In the workspace I use for my codebase (~382k lines, 305 projects with standalone deps.edn
) I only create workspace folders for the projects I work with most regularly, for everything else I can just access them from the root folder.
So the reason to add them as workspace folders is just for "focus"?
Used to use it for my OSS projects -- and probably will go back to that now that LSP works across projects -- but for work, we do everything via the project root so it's a single workspace.
> So the reason to add them as workspace folders is just for "focus"? Pretty much just to keep my explorer organized, yes.
Hmm so this does seem to be the core of the issue, the same LSP server cannot be shared across multiple workspace roots.
Previously, were you finding different behavior opening a file between your root project (with LSP running) and the same file in subfolder project (without LSP running)?
No, as far as I know VS Code doesn't allow this. VSC seems to always default to opening the file from the nearest workspace root. So if I have a file like liftoff/foo/deps.edn
and I have foo
setup as a workspace root, the breadcrumbs will always show foo/deps.edn
and the explorer will be focused on the file within the foo
workspace root, even if I first selected the file from within the liftoff
workspace root.
I think for now I'm just going to remove most of these workspace folders to get things working again. Initially I didn't realize that the issue was isolated to projects that are nested within additional project roots.
> having the default be to just start one LSP server in the first workspace folder as before would probably make this less painful for people That's how it is intended to work. If it doesn't, then there is a bug/error in how we have thought about it/implemented it.
> Now I start up Calva and all of the sudden I'm running dozens of LSP processes Please report this bug as an issue. If you can provide a reproduction repository, that would be extra great.
> I do wish major changes like this could be introduced in more backward-compatible way. We tried. It was meant to be working just as before for with the default settings.
Sounds good. If this is not the intended behavior I'll open a GitHub issue. Maybe part of the confusion comes from the way the default setting when-workspace-opened-use-workspace-root
is described with regards to multi-root workspaces, since in a multi-root workspace there's no single workspace root, so running multiple LSP processes in a multi-root workspace seemed to be intentional.
Issue welcome! And let’s get that description fixed too. You’re welcome to file an issue about that too.
@UQE9SS4DP When you get a chance can you try this vsix build: https://output.circle-artifacts.com/output/job/f31988e5-0764-477c-a614-138617ecf7fe/artifacts/0/tmp/artifacts/calva-2.0.332-pull-2075-54eeed90.vsix - it should resolve the issue you are experiencing.