This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (15)
- # babashka (2)
- # beginners (90)
- # cider (3)
- # circleci (1)
- # clj-kondo (5)
- # cljs-dev (7)
- # clojure (49)
- # clojure-australia (9)
- # clojure-berlin (3)
- # clojure-dev (1)
- # clojure-europe (58)
- # clojure-nl (3)
- # clojure-norway (1)
- # clojure-uk (7)
- # clojurescript (66)
- # code-reviews (1)
- # community-development (3)
- # conjure (47)
- # datomic (57)
- # emacs (4)
- # fulcro (5)
- # graalvm (1)
- # introduce-yourself (7)
- # jackdaw (1)
- # jobs (2)
- # kaocha (4)
- # lsp (87)
- # nrepl (1)
- # off-topic (33)
- # pedestal (7)
- # portal (12)
- # re-frame (7)
- # reitit (11)
- # releases (1)
- # ring (1)
- # rum (7)
- # sci (2)
- # shadow-cljs (38)
- # sql (15)
- # vim (2)
hi there! I tried to integrate clojure-lsp-native with sublime text but unfortunatelly getting strange exception filed it here - https://github.com/clojure-lsp/clojure-lsp/issues/430
On the subject of Sublime Text, I've been working on a Clojure package for ST for the past year or so. I've recently been migrating it off of nREPL to socket REPL and adding ClojureScript support (shadow-cljs only for now). If you're interested in trying it out, let me know.
Just asking because the version that's in Package Control still uses nREPL -- it's pretty old now and I'll be dropping nREPL support in the next version.
I sadly didn't have the time to get everything into shape for the ST4 release, so no documentation yet, but the long and short of it is that just run Tutkain: Connect to connect to a Clojure, shadow-cljs, or a Babashka socket REPL, run Tutkain: Edit Key Bindings to see a bunch of example key bindings, copy-paste and edit what you need, and you should be off to the races.
I've now deployed the latest version into Package Control, so instead of using the master branch, you can just update via Package Control. Probably need to restart ST. I've also updated the documentation at https://tutkain.flowthing.me/.
It seems other editors (vim, emacs, vscode ) doesn't use that class for some reason
@U04V4KLKC Fixed on master, besides the option mentioned above, you can build a new image following https://clojure-lsp.github.io/clojure-lsp/building/ or wait for the next release which should be soon
so far I just download clojure-lsp.jar and use it like that:
["java", "-jar", "/path/to/jar"]
no it complain about org.eclipse.lsp4j.MarkdownCapabilities I’ll fix it and make a PR later today. Will check if anything else is missing
Hey guys, With
lsp installed and enabled and - with my point in Emacs on one of the core clojure symbols like
println - invoking
lsp-find-definition takes a long while and the performance of
cider-find-var has also regressed for me. In each instance, Emacs is blocked while a new LSP server seems to be starting up on a new port!
we had a recent change that made use the lib as the same workspace avoiding connecting a new clojure-lsp as a new workspace
Thanks @UKFSJSM38; I updated all my Emacs packages today. I’ll check the version and let you know.
The “new workspace” path, in the case of
lsp-find-definition, ends up being ~/.emacs.d/workspace/.cache/.
And in CIDER’s case, ~/.m2/repository/org/clojure/clojure/1.10.2/clojure-1.10.2.jar:clojure/.
lsp-session-file contained my ~/.emacs.d directory from my LSP use a while ago.
I fixed that by clearing the session file; a cleanup was useful for my purposes anyway. 🙂
I noted that since the session file reset, I’ve only opened one project with LSP but it seems to have automagically added an entry for my home directory as well; I am guessing because of the
#s(lsp-session ("/Users/affan" "/Users/affan/scratch/clj/rdd-demo") nil #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ()) #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ()) #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ()))
I always had issues with cider-find-var, sorry, maybe you can get that answer on #cider
Hm, after successful removal (both from the LSP completion list and the session file), it added it back in when I tried
lsp-mode has nothing related with cider, that command only removes the folder as root, so next time you
lsp it will ask what's the project root
The reason this ends up related is because, like the recommended configuration, I’ve got
lsp activated through
clojure-mode-hook so when
cider-find-var takes me to a new Clojure file,
lsp kicks in.
And that’s when the session file is checked while deciding whether a new LSP server is needed. At any rate, I think I’ve worked out the cause for the home directory returning; this is because I’ve got
lsp-auto-guess-root enabled and in that case projectile state also needs cleaning up.
I see now, yes, lsp-auto-guess-root is not enabled by default for those kind of issues, I suggest disable it indeed
Ah, I see. I followed your useful guide amongst other resources but did not come across that.
I think I’d prefer
lsp-find-definition but I’m running into a significant slowdown (and UI blocking) on the first access to a file like
which-func-ff-hook error: (error "Timeout while waiting for response. Method: textDocument/documentSymbol")
It seems like my generally useful
which-func-mode is waiting for the symbol information from LSP (probably indirectly), hm…
Hm, it times out but only on the
clojure.core.clj file. At least, it’s fine on the small project files that I’ve tested
lsp with so far. :)
I was able to resolve this by lowering
which-func-maxout to 5000 with a
setq-local for my
Yeah, could you check your clojure-lsp.out log file? To get how much time it's taking the request
Ah, that’ll be useful because while find-file is no longer blocking (and that timeout error’s gone), there’s still a significant period of UI blocking immediately after the file loads up.
I’ve created a Gist: https://gist.github.com/affan-salman/78568d35119bc483b8eeb899d4a32710
I can only see didOpen taking to much time, but I think it's ok since it's scanning clojure.core and it's a huge buffer
Right. 🙂 That ~28secs on didOpen does feel slightly painful. There’s a long while of UI not responding, of course 🙂
I mean that trying to navigate in the file is prevented for a while. For instance, pressing C-n to move to the next line does not respond.
Hum, that shouldn't happen as lsp-mode is just starting/opening a file, it shouldn't block emacs
Ah, cool … I’ll be able to resume tomorrow and this will be a useful starting point. Thanks, @UKFSJSM38 🙃
Hi @UKFSJSM38, I resolved the remaining part of it by setting
nil. (Without it,
which-function is triggered which waits on LSP thus freezing Emacs.)
Nice, I intend to spend some time taking a look on performance, that should help this issue as well