has anyone noticed something similar

could you try from the terminal to make sure it's not a editor issue:

clojure-lsp clean-ns

I also noticed that I might be using an old versioin, since the homebrew is much older than the one that emacs downloads automatically

yep, use the official brew tap https://clojure-lsp.io/installation/#homebrew-macos-and-linux

Executed in 10.48 secs fish external usr time 23.09 secs 48.00 micros 23.09 secs sys time 1.28 secs 770.00 micros 1.27 secs time clojure-lsp clean-ns [ 99%] Project analyzed Checking namespaces... Nothing to clear! ______________________________________________________ Executed in 5.90 secs fish external usr time 18.05 secs 53.00 micros 18.05 secs sys time 0.63 secs 911.00 micros 0.63 secs

well it does take a while

even after the first run

first please update clojure-lsp following the link I mentioned

time clojure-lsp clean-ns
[ 99%] Project analyzed            Checking namespaces...
Nothing to clear!

________________________________________________________
Executed in    1.91 secs    fish           external
   usr time    2.39 secs    0.06 millis    2.39 secs
   sys time    0.25 secs    1.01 millis    0.25 secs

oh yeah better now

I wish we could remove that clojure-lsp from the homebrew core, it's outdated and maintainers don't want to remove it.

all because they don't want to download the native binary, but use the JVM one

still takes a while actually, but I wonder if it's using the one in .emacs.d

it's probably using the one from emacs

lsp-uninstall-server

and let it use the one that you downloaded

ah wait, it actually ddoes the thing but

lsp-workspace-command-execute: 'workspace/executeCommand' with 'clean-ns' failed.

(error "Timeout while waiting for response.  Method: workspace/executeCommand")

that's weird, make sure it's using the updated one with lsp-clojure-server-info , it should print on messages buffer the server-version

:server-version "2024.03.31-19.15.11-nightly",

looks correct

but yeah still happening even after I restarted Emacs

so it's fast on terminal but slow on emacs?

yeah looks like

try the profile again

weird that it says it times out but it still does it

it's weird tho

Actually in case if someone uses mise or asdf I made plugin https://github.com/armed/asdf-clojure-lsp

ok I still haven't solved this issue, lots of refactoring timeout for some weird reason from Emacs

but others like rename are just perfectly fine

actually the rename is just lsp-rename , probably all the ones starting with lsp-clojure- are not actually working

Checking for Native JSON support: OK
Check emacs supports `read-process-output-max': OK
Check `read-process-output-max' default has been changed from 4k: OK
Byte compiled against Native JSON (recompile lsp-mode if failing when Native JSON available): OK
`gc-cons-threshold' increased?: OK
Using `plist' for deserialized objects? (refer to ): OPTIONAL
Using emacs 28+ with native compilation?: OK

the doctor also seems happy

well maybe I should enable plist as well

Cancelling textDocument/documentHighlight(53746) in hook after-change-functions
Cancelling textDocument/codeAction(53745) in hook after-change-functions
Cancelling textDocument/codeAction(53783) in hook after-change-functions
Cancelling textDocument/codeAction(53807) in hook after-change-functions
Cancelling codeLens/resolve(53806) in hook after-change-functions
Cancelling textDocument/codeAction(53816) in hook after-change-functions
Cancelling codeLens/resolve(53815) in hook after-change-functions
Cancelling textDocument/documentHighlight(53823) in hook after-change-functions
Cancelling textDocument/codeAction(53822) in hook after-change-functions
Cancelling codeLens/resolve(53821) in hook after-change-functions
Cancelling textDocument/documentHighlight(53826) in hook after-change-functions
Cancelling textDocument/codeAction(53825) in hook after-change-functions
Cancelling codeLens/resolve(53832) in hook after-change-functions
Cancelling textDocument/documentHighlight(53839) in hook after-change-functions
Cancelling textDocument/codeLens(53836) in hook after-change-functions
Cancelling textDocument/documentHighlight(53846) in hook after-change-functions
Cancelling textDocument/codeLens(53843) in hook after-change-functions
Cancelling textDocument/documentHighlight(53882) in hook after-change-functions
Cancelling textDocument/codeAction(53881) in hook after-change-functions
Cancelling codeLens/resolve(53972) in hook after-change-functions

I can see a bunch of these

not sure how easy would be, also, not sure it's clojure-lsp fault or your editor's lsp client side

I guess you’re referring to Calva here?

I’m referring to this UI

yes, not sure why clojure-lsp would lock or freeze things

cc @U0ETXRFEW thoughts on this?

I’m thinking that Calva could very well start acting up on broken structure. But you say that with clojure-lsp disabled it starts to work again. If I can get a repro I can investigate and see if there is something in the lsp-support from Calva that causes it. Well, I can try at least.

I think what is needed is a big clojure repository with many source files and projects. And both extensions. Also it is not completely blocking, it just making it very slow. I believe Clojure LSP is trying to catch up with the new changes applied in a rebase and until it’s done, the UI is not refreshing. So I’m using “Calva Clojure LSP: Stop the Clojure LSP server” in such situations to speed things up. Do you know any big open source repo I can try it with?

Penpot, http://status.im, metabase are the ones popping to mind.

LSP does have a file watch feature which the editor send to clojure-lsp all changed files outside the editor (because of a git rebase for example), then clojure-lsp analyze in batch the files, but that should be as fast or faster than analyzing the whole project when starting, sounds like we would need a good repro to undertand it better

Perhaps the watcher is being triggered once per operation/commit (vs once per rebase)?

Interesting, we have a fairly massive mixed clj/s (lein monolith-powered) mono repo, the kind of setup where many c-lsp features break down, but gitlens diff etc has not been one of them for me over the past couple years