Clojurians Log v2
lsp 2026-06-28
Please do!
Has anyone tried using flowstorm to debug clojure-lsp? I'm using println and def to debug and feel like I'm dragging my knuckles, so I'm looking for something better. It seems like flowstorm should work, but before I try setting it up I figured I'd ask around.
I think some people used but I never got used to flowstorm workflow but I do think it's awesome for people that know how to use it.
Usually I just use lsp-clojure-nrepl-connect to get a repl to my running clojure-lsp and then eval stuff there
I was just looking into https://github.com/clojure-lsp/clojure-lsp/issues/2139 (Drop restriction on renaming unqualified keywords from @borkdude and @ericdallo). I suspect that the fix is trivial. I removed the check in rename/rename-status and clojure-lsp seems to rename unqualified keywords without any problem. However... the discussion in the bug was /why/ was it disabled.
I've noticed that with the restriction disabled, I can do dumb things like rename :require, :refer, and :as (from the ns macro) as well as the keyword :private in ^:private . Beyond keywords, clojure-lsp allows me to attempt to rename clojure core things like defn and let, but those LSP requests eventually fail. But, it lets me rename string/starts-with?, at least in my local files - fortunately it can't modify the files in clojure-1.12.2.jar.
As it stands, when I wanted to do this myself, I used the vscode global replace function. That does almost same thing as rename, with maybe slightly more downsides in that it not be syntax aware so could change comments, function names, etc... .
I don't know what the right thing to do is, but since the fix is so easy, I thought I might bring it up here to see what people think.
I got this kinda working. But... it kinda is a small footgun. In playing around with it, I've accidentally made a bunch of changes to keywords that spread into other files. An example of this is the tests - there's a bunch of :a, which I renamed, and then I had like a dozen files with changes. I can imagine this happening with :id, :name, etc...
I'm wondering if we should start to introduce LSP's needs-confirmation annotation, perhaps for changes that exceed one file?
I hacked clojure-lsp up and sent a reply with needs-confirmation to Calva, and I get this UI:
I can publish the PR as it is now (/soon) though, if people think this behavior is OK for now. We can talk about requesting a refactor preview later...
oh last time I checked there was no way to have a confirmation dialog for this, interested on how you did it, but yes, a dialog is ideal for this
The hack was to make shared/client-changes return this (hardcoded for testing):
{
:document-changes [
{
:text-document {
:version 388,
:uri "file:///home/john/Projects/clojure-lsp/lib/src/clojure_lsp/refactor/mytest4.clj"
},
:edits [
{
:range {
:start { :line 13, :character 0 },
:end { :line 13, :character 10 }
},
:new-text "::my-a-kw5",
:annotation-id "confirmClojureRefactor"
}
]
}
],
:change-annotations {
"confirmClojureRefactor" {:label "Confirm Clojure Refactor",
:needs-confirmation true,
:description "Reviewing keyword replacement in mytest4.clj"
}
}
}oh I missed that from protocol, that's quite clever! looks good to me, and yes we can use for more commands, I wish there was a way to specify options for user to choose, not only a confirmation yes/no, but that's good for this feature. Just remind that we should check for client capability before returning those (unless it's ok add this and clients that don't support will ignore, I think they will), I can add support for this in emacs lsp-mode later
I think the user can select to allow/disallow changes, so it's a little more than a binary confirmation. It's perhaps not quite as fully featured as Intellij though. > client capability Good call! I filed https://github.com/clojure-lsp/clojure-lsp/issues/2370 for this. I can look at it soon.
yeah, I think we should do it. Maybe having a internal denylist of kwds we should not allow renaming, but I'm pretty ok allowing this