This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-25
Channels
- # announcements (4)
- # babashka (13)
- # beginners (115)
- # cider (62)
- # clj-kondo (16)
- # cljdoc (4)
- # cljs-dev (5)
- # clojure (44)
- # clojure-europe (57)
- # clojure-greece (1)
- # clojure-italy (2)
- # clojure-nl (3)
- # clojure-spec (2)
- # clojure-uk (24)
- # clojurescript (58)
- # code-reviews (2)
- # community-development (6)
- # conjure (3)
- # core-async (9)
- # cursive (34)
- # datahike (3)
- # datalog (1)
- # datomic (67)
- # emacs (9)
- # events (5)
- # fulcro (9)
- # graalvm (1)
- # jobs (1)
- # lsp (24)
- # off-topic (20)
- # pathom (17)
- # polylith (11)
- # re-frame (21)
- # react (21)
- # reagent (3)
- # reitit (23)
- # releases (1)
- # remote-jobs (1)
- # ring (3)
- # sci (47)
- # tools-deps (7)
- # vim (15)
- # xtdb (4)
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
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
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
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 @U04V15CAJ?
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 @U0BUV7XSA as it has a lot of diagnostics
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
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 @U0BUV7XSA could you take a look please? @U11BV7MTK It'd be great if you could test it the changes as well