Clojurians Log v2

ATM this is not automatic unless you force cache removal or open the changed namespace manually in the editor... THe issue is that there is no way checking the classpath string to know that that code changed

and even if had, you would still need to restart LSP, so maybe remove the .lsp/.cache is easier for now

thank you!

I found in the https://clojure-lsp.io/clients/ the following statement: > Clients are responsible for launching the server, the server is a subprocess of your editor not a daemon Does this means that it's not possible to communicate because of the way clojure-lsp was designed? Or something inherent about lsp protocol?

I never saw someone spawning a LSP client and connecting from the editor like a repl, I don't think this is possible/expected to work

the editors usually have the logic to spawn the process and send/receive via stdio

@franquito whats the usecase for not waiting? are you seeing too long times to boot?

It takes 30 seconds to start in my work project, which I suppose is not long? I just tend to open/close vim, sometimes I have 2 vims open.

shouldnt take that long once the initial indexing is done. should be few sec at max after that. its it the native executable youre using?

30s is definitely too long

also whats your setup? vim or neovim and what kind of lsp setup are you using?

Native executable, neovim v0.9.1 + neovim/nvim-lspconfig plugin

clojure-lsp 2023.05.04-19.38.01
clj-kondo 2023.04.15-SNAPSHOT

is it always 30s? even when you let it complete indexing?

if its always 30s something could be up lsp itself which getting triggered by your code. cc @ericdallo

(this only happens in my work code base)

yeah its a combo of .lsp/.cache and .cpcache

Maybe Eric knows better if something's getting triggered in lsp due to the codebase

unless you have a really huge project, 30s is not expected

check https://clojure-lsp.io/troubleshooting/#server-log if mentions that is using the cache or not

also for huge projects, subsequent runs should be quicker too right?

yep, unless your project has tons of namespaces which will always be analyzed

the external classpath is cached the project code, not

Looks like clj-kondo is taking 20 secs

2023-07-28T19:19:34.367Z  INFO [clojure-lsp.startup:71] - [Startup] Project only paths analyzed by clj-kondo, took 20283ms

i suppose it could be hitting the "lots of namespaces needed to be analysed" issue maybe? or maybe even asking this in #clj-kondo could be worth it too?

I have 600 namespaces

well that could be it

Damn 🥲

not sure, im no expert here 😛

id say ask in #clj-kondo too just to be sure

Don't sell yourself too short!

Yes, basically the logs say most of the upstart time is clj-kondo stuff. Thank you both! 🙏

yeah, 20s for 600 makes sense, it depends on the size of each namespace as well