This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-13
Channels
- # announcements (1)
- # babashka (12)
- # beginners (10)
- # biff (9)
- # calva (2)
- # cherry (21)
- # cider (14)
- # clj-commons (76)
- # clj-kondo (8)
- # clj-on-windows (34)
- # cljs-dev (5)
- # clojure (48)
- # clojure-austin (7)
- # clojure-europe (97)
- # clojure-nl (1)
- # clojure-norway (14)
- # clojure-uk (22)
- # clojurescript (137)
- # conjure (33)
- # cursive (4)
- # datalevin (1)
- # deps-new (4)
- # devcards (2)
- # duct (3)
- # events (1)
- # fulcro (12)
- # graphql (9)
- # hyperfiddle (16)
- # jobs (8)
- # kaocha (1)
- # leiningen (6)
- # lsp (39)
- # malli (38)
- # membrane (20)
- # nbb (68)
- # observability (7)
- # off-topic (49)
- # pathom (11)
- # polylith (8)
- # portal (22)
- # re-frame (6)
- # releases (1)
- # remote-jobs (2)
- # shadow-cljs (24)
- # spacemacs (2)
- # squint (6)
- # xtdb (7)
How about a move-to-param
(like move-to-let
) refactoring which adds a param with the given name and replaces all cases of the expression under the cursor with it?
Would it add a new arg to the function, changing its arity right? what about the callers of that function? they would need to pass the new arg usually we avoid refactorings that break the code or leave the code invalid
@UKFSJSM38 yes, you're right. Unless it's added as a kwarg with a default it would be a breaking change and updating all the call sites would probably bring too much complexity to the UI and the handling code. Thanks for your consideration.
So I think intellij (java) allows this, maybe with a static value (nil) for the new arg at call sites or perhaps it requires the interactive refactoring feature. This is related, but with drag it's using existing args. https://github.com/clojure-lsp/clojure-lsp/issues/1131
https://www.jetbrains.com/help/idea/change-signature.html#change_class_signature_refactoring
Yeah, the LSP protocol doesn't mention a "update multiple places" feature, but thinking a little bit maybe this is something that should be handled by each client, like server tells, update file a
, b
and c
with these changes, and each client handle how to present to user with a confirm or rollback option. At least would be nice if the the protocol should be clear about that or suggest something
Even so, I don't recall most clients (vim, emacs and vscode) having a feature like that which intellij has
Yeah, without protocol direction though I wouldn't want clients to have to build clojure-lsp specific handling. We can do the static value insertion without the suggestion/review feature tho
Similar to the "any var" option we could look for vars whose names match the new param name too, but that might run into too easy to break/too hard to review manually.
Has anyone else been seeing codeAction errors? I’ve seen something like this in Calva lately, multiple times, and a friend has as well.
[Error - 10:51:40 AM] Request textDocument/codeAction failed.
Message: Internal error
Code: -32603
[object Object]
The client<->server comm looks like this:
[Trace - 11:53:37 AM] Sending request 'textDocument/codeAction - (56)'.
Params: {
"textDocument": {
"uri": "<my-file-path>"
},
"range": {
"start": {
"line": 62,
"character": 28
},
"end": {
"line": 62,
"character": 28
}
},
"context": {
"diagnostics": [],
"triggerKind": 2
}
}
[Trace - 11:53:37 AM] Received response 'textDocument/codeAction - (56)' in 17ms. Request failed: Internal error (-32603).
Error data: {
"id": 56,
"method": "textDocument/codeAction"
There’s a null pointer exception in the server logs:
2022-09-13T18:53:37.963Z ERROR [clojure-lsp.server:39] - Error receiving message: Internal error (-32603)
{:id 56, :method "textDocument/codeAction"}
[37mcom.oracle.svm.core.posix.thread.PosixPlatformThreads.pthreadStartRoutine[m [32mPosixPlatformThreads.java: 202[m
[37mcom.oracle.svm.core.thread.PlatformThreads.threadStartRoutine[m [32m PlatformThreads.java: 705[m
[37mjava.lang.Thread.run[m [32m Thread.java: 829[m
[37mjava.util.concurrent.ThreadPoolExecutor$Worker.run[m [32m ThreadPoolExecutor.java: 628[m
[37mjava.util.concurrent.ThreadPoolExecutor.runWorker[m [32m ThreadPoolExecutor.java: 1128[m
[37mjava.util.concurrent.FutureTask.run[m [32m FutureTask.java: 264[m
[37m...[m [32m [m
[33mclojure.core/binding-conveyor-fn/[1;33mfn[m [32m core.clj: 2047[m
[33mclojure-lsp.feature.code-actions/all/[1;33mfn[m [32m code_actions.clj: 329[m
[33mclojure-lsp.feature.drag/[1;33mcan-drag-backward?[m [32m drag.clj: 493[m
[33mclojure-lsp.feature.drag/[1;33mcan-drag?[m [32m drag.clj: 492[m
[33mclojure-lsp.feature.drag/[1;33mplan[m [32m drag.clj: 483[m
[33mclojure-lsp.feature.drag/[1;33mtarget-locs[m [32m drag.clj: 476[m
[33mrewrite-clj.zip/[1;33mnode[m [32m zip.cljc: 178[m
[33mrewrite-clj.custom-zipper.core/[1;33mnode[m [32m core.cljc: 55[m
[33mclojure.zip/[1;33mnode[m [32m zip.clj: 67[m
[1;31mjava.lang.NullPointerException[m: [3m[m
[1;31mjava.util.concurrent.ExecutionException[m: [3mjava.lang.NullPointerException[m
This happens to me all the time and is quite annoying. I'm a bad Clojure citizen for not reporting. 😃 Anyway, super easy to repro. Just ignore a binding pair in a map or let box by prepending it with #_#_
.
(let [x 1
y 2]
x)
Make that:
(let [x 1
#_#_y 2]
x)
BOOM.I think that was fixed on master https://github.com/clojure-lsp/clojure-lsp/pull/1228 Could you test the nightly build?
@UKFSJSM38 Where can I get the nightly builds?
Does the install script install the latest? And does the nightly build report the last released version when --version
is run?
the install script uses the latest stable release unless you pass the --nightly param
Just downloaded the nightly build zip from the builds channel and it also reports the latest release, so I guess it is the nightly build..
Anyway, I confirmed that the nightly build fixes the issue, using the repro from @U0ETXRFEW above. 🎉
Yeah, maybe we lost that suffix after we recently moved nightly builds to a separated repo, which made us refactoring the nightly build CI
from clojure-lsp side, it seems the version output is correct @U9A1RLFNV :thinking_face:
This is what I get with the nightly build I downloaded for macos-aarch64:
./clojure-lsp --version
clojure-lsp 2022.09.01-15.27.31
clj-kondo 2022.09.08
oh, there is a chance to be only with macos-aarch64, since it's the only build which is built from cirrus-ci (github doesn't support aarch64 yet)
@U9A1RLFNV I think it's fixed, could you test it again please?
Works 🎉
./clojure-lsp --version
clojure-lsp 2022.09.15-16.16.12-nightly
clj-kondo 2022.09.08

I’m not sure. @U0ETXRFEW would you mind verifying that?