I'm seeing quite long freeze-ups when opening buffers for the first time. latest lsp, emacs 27.2
lsp-mode should not block open buffers or anything unless you are trying to use some lsp function like go-to definition
do you have a repro?
right now it is consistent when opening a buffer for the first time
every buffer? only large ones? it freezes even if not typing anything?
so far each new buffer yes. they aren't particularly large. I open my file chooser, select the buffer and it freezes for about 20 seconds with the file chooser open. after about 20 seconds it then displays the buffer. during the freeze no interaction with emacs, tabbing away and back it takes about a second for emacs to become visible
that's odd.. could you try to reproduce with lsp-start-plain.el ?
I'm seeing > Warning (flycheck): Syntax checker lsp reported too many errors (602) and is disabled. Use ‘M-x customize-variable RET flycheck-checker-error-threshold’ to change the threshold or ‘M-x universal-argument M-x flycheck-disable-checker’ to re-enable the checker. > Warning (flycheck): Syntax checker lsp reported too many errors (967) and is disabled. Use ‘M-x customize-variable RET flycheck-checker-error-threshold’ to change the threshold or ‘M-x universal-argument M-x flycheck-disable-checker’ to re-enable the checker.
https://github.com/emacs-lsp/lsp-mode/blob/master/scripts/lsp-start-plain.el#L23-L30
perhaps its only for buffers where it thinks there are lots of errors
i'll try that in a second. profiler reports the time was spent in the clojure-mode hooks which would be lsp i believe
I am also seeing long freezes when opening buffers, it was also mentioned in #emacs. Not sure if I'm on the newest stuff though.
Could you test it on latest release @borkdude?
ok I will update
Ok, I think I found something: Testing on clojure-lsp project, if the buffer has a lot of diagnostics (erros/warrnigs), the didOpen request takes too much time (it went from 300ms to 10s adding 300 unresolved vars) and then I get the freeze if edditing the buffer while didOpening... That could explain that high amount of time on clojure.core buffers @snoe as it has a lot of diagnostics
also, it doesn't seems related with recent releases
that would be similar to my scenario. lots of testing macros which don't have info for kondo to parse, so are just opaque errors to it
yeah, lsp-mode should not block even with didOpen taking to much time, even so, we should fix that time on clojure-lsp
is there enough information for a repro?
yes, I'll try to check on clojure-lsp side, but it'd be good to check why lsp-mode freezes as well
So, it's clojure-lsp code that is taking too much time , I'll take a closer look
I wonder if this is related - we're sending duplicate completions (again) I wonder if we're sending diagnostics multiple times too.
I'm not aware of duplicated completions, but I found the lint issue, it 's related with using rewrite-clj to parse the text every lint for checking if it's starts with (
, this drastically reduced the time on clojure.core from 40s -> 13s, I'm still investigating what else is taking time and then I'll try to improve fix those things
So, after a lot of debugging, I created this PR with the changes/improvements: https://github.com/clojure-lsp/clojure-lsp/pull/435 @snoe could you take a look please? @dpsutton It'd be great if you could test it the changes as well