This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-12
Channels
- # adventofcode (80)
- # announcements (11)
- # babashka-sci-dev (6)
- # beginners (52)
- # calva (144)
- # clj-kondo (28)
- # cljdoc (2)
- # cljs-dev (7)
- # clojure (120)
- # clojure-dev (28)
- # clojure-europe (36)
- # clojure-nl (1)
- # clojure-norway (16)
- # clojure-uk (3)
- # clojurescript (1)
- # cursive (4)
- # datomic (14)
- # figwheel-main (5)
- # fulcro (23)
- # hoplon (2)
- # hyperfiddle (46)
- # improve-getting-started (10)
- # jobs (1)
- # joyride (1)
- # leiningen (10)
- # malli (5)
- # nbb (5)
- # off-topic (21)
- # polylith (7)
- # portal (15)
- # practicalli (1)
- # rdf (18)
- # re-frame (3)
- # releases (2)
- # remote-jobs (5)
- # shadow-cljs (25)
- # spacemacs (4)
- # tools-deps (16)
- # tree-sitter (1)
I finally made the switch to Calva after my spacemacs setup broke in mysterious ways for the umpteenth time after an update. I've been spending the last few days getting things configured while doing the advent of code and couldn't be happier with how easy it's been and how discoverable the functionality is. Thank you @pez and everyone else who has contributed to the project, it's been a breeze to use!
You are welcome, @UG00LE5TN ! Thanks for letting us know about this.
I was very frustrated recently with VSCode, it was extremely laggy, couldn't scroll, couldn't type. I started deactivating plugins etc etc but in the end even with no plugins, I saw random 100% cpu spikes from the main process. Do you want to know how I fixed it?
Depends on wether you had reloaded the VS Code window after disablement. That requires a reload to take effect.
Even that. If you had reloaded the window with Calva disabled, then Calva is not causing the behaviour.
It won't help with a weird situation like you had, because that seems to be VS Code that had accrued some state that it needed a restart to get rid of.
Yep, that seemed to be the case. It seems like a proper restart helps every now and then.
Maybe, but I killed 35 days of uptime today for other reasons. (Finder open dialog stopped working in Chrome). Had 17 VS Code windows with no issues. Granted, I have restarted VS Code to update it some weeks ago. That said. I have tried to help users now and then, where things needed a VS Code restart, so sure it does happen.
That's funny because my REPLs stay up until I have to restart Windows (or WSL2) for stuff but VS Code seems to want to be reloaded every few days for me for updates -- or do you just ignore the blue dot indicating extensions want to be updated? I just can't ignore that! 🙂
There's a difference between VS Code window reload and VS Code restart here. Each window has its own extension host so you can get new versions in place in one window by reloading it, without restarting VS Code.
Yeah, which just means that I have blue dots begging for attention in multiple windows! :rolling_on_the_floor_laughing:
(I know there's a setting to turn the blue dot off... but then I'd be forever checking for new extension versions manually! argh!)
Or I could just blame you for constantly releasing new versions of Calva and Joyride! :rolling_on_the_floor_laughing: Yeah, that's it, it's all your fault!
If you run Joyride in development you can just pull the changes and the extension will update without any reload needed. 😃
A reload is quite cheap indeed, it just costs me my REPL connection, and a clojure-lsp startup time. But I will do hard restarts more often now that I saw that VSCode is actually a bit leaky too.
Hi Calva friends, another question today: Is it possible to change the order in which the example and the linter warnings are shown? clj-kondo warnings are shown after a long docstring comment, and I have to scroll down every time in order to see it. I'd like the warning to appear before the example documentation, since it's more important
No, not possible. Have a look at the Error Lens extension and see if that can mitigate this a bit for you.
Is this the kind of thing that could be changed in calva, or is it truly impossible? This one is a frequent annoyance for me too
I could be wrong though. It is hover providers at work, if someone wants to investigate it.
If you have reasons to think there is API for it, then yes. Otherwise no. Or create one and close it, so that if someone searches for it they can find it and see that it can't be fixed. Depends on what your goal with an issue is. 😃
So that someone remembers to look at it at some point. I don’t have time today for example
Yeah, sounds like an issue. Name it something like Investigate if there is API for floating the problem reports higher in the info-hover Please be the one to remember to look at it and close it when its done. 😃
I had a free minute and started poking at this, but having trouble navigating calva’s and vscode’s codebases without a lot of experience in vscode extension land. @pez would you mind pointing me to the part of calva’s code where the kondo error comes from?
@U01EB0V3H39 This happens in src/lsp/main.ts
. When we create the LSP client we register middleware, and this would be the handleDiagnostics
middleware, I think. And the hover is created by the provideHover
middleware.
It looks like provideHover
only adds the docs and clojuredocs example parts. I’m assuming the diagnostics part is added in inside vscode? If so, it appears there is no API that can be used to fix this.
Given that, it may be worth considering other angles to approach this problem from. On one hand, people want to have clojuredocs info/examples readily available. On the other, it seems like hovers should be kept short enough so they don’t need to be scrolled to see diagnostics info (which seems in line with what I’ve seen other language integrations do). It’s definitely a tricky problem, I wonder if there’s a different place the clojuredocs info could be shown? Or maybe clojuredocs should only be shown in “advanced hover info” (I think in some extensions additional info shows up when you hold cmd or alt or something?)
Sorry for the radio silence! Please file an issue about this, @U01EB0V3H39. Not sure what a good solution is, but the problem pops up often enough for it to warrant a discussion about the options.
Do you want to repurpose https://github.com/BetterThanTomorrow/calva/issues/1998 or should I file a fresh one? There’s not much on it, I could just change the title and note my findings
I think it makes most sense to add your findings to that issue and close it. And open a new issue for the problem.
I created a #joyride script that solves this by adding another diagnostics hover item at the top of the hover: https://github.com/BetterThanTomorrow/joyride/blob/master/examples/.joyride/src/problem_hover.cljs
So it just copies the problem report to the top? That’s an interesting idea. What’s it look like?
That could be a good solution. If it was done in calva, it could be put between the docs and the examples
Some docs are pretty big, so it makes most sense to stick this at the top. And also makes most sense as a user config with Joyride.
The one drawback I suppose is that I remember there being actions associated with problems, and those would remain below the fold, right?
Quick fix? Yeah, but that's easier to use via a keyboard shortcut, anyway. But you can add that as well there, I think.
Just tried it. You can show the actions, but it behaves a bit weird, so I'm rating it Mostly false.
Now that I’m back at a computer, it looks like there’s two buttons in the normal problem display. So it sounds like those can’t be replicated well in a custom hover section?
> And also makes most sense as a user config with Joyride. I’m curious about this bit, what’s the rationale for not adding this to Calva? I’d think in the spirit of having a good experience out of the box, you’d want users to have access to Clojuredocs examples and be able to easily see problem reports
The problem is more general than Calva. Could be something you employ for other language hovers as well, and if you do it broadly, then if Calva adds it, you'll have three diagnostics items for the same problem in the hover.
> it sounds like those can’t be replicated well in a custom hover section? Correct. There doesn't seem to be an API for ”View Problem”, and when I tried adding the command (something a bit close to ”View Problem" exists, for both the hover stays up when you use the commands.
Are there other places where it might make more sense to show clojuredocs examples? Like, what if there was a link/command/whatever to pop them up in a webview to the side?
I'd say they make most sense in the hover. That's also where clojure-lsp puts them. It gets a bit strange if they disappear from there when the REPL is connected.
I agree that calva shouldn’t make the change alone, but perhaps clojure-lsp should also consider moving/giving an option to move it
Like, fundamentally the current behavior is a meh experience out of the box for everyone, why wouldn’t we want to improve it?
FWIW: I’ve not seen any other VSCode language extension where such lengthy examples are shown in the hover info. Personally I don’t think that’s the correct place for it, IMO on-hover should only show the function docstring
Furthermore, the examples are hard to read in that small space. Accidentally moving the mouse out will close the pop up, it’s hard to copy paste, etc. it’s not the best experience having it in there. I’d prefer just a link to the docs that I can click if I need it
There’s a past discussion around where to show the clojuredocs material (before it was added to the hover) here: https://github.com/BetterThanTomorrow/calva/issues/689.
(defn foo
([x])
([x y]))
(foo :foo|) ; <- cursor here
Pressing spacebar
(in addition to adding a space) triggers a popup.
1/2 (foo [x])
And pressing ↑
or ↓
changes the popup to
2/2 (foo [x y])
I find this popup super frustrating because it cycles continuously. This prevents using ↑
or ↓
for movement, until I either stretch up to the Esc
key or somehow get the cursor all the way outside the function expression.
Do you know if that can be changed somehow?Sweet! Your answer was slightly off target, but gave me enough terminology to find editor.parameterHints.cycle
.
Now up goes up or to previous line and down goes down or to next line, instead of looping around endlessly.
I’m late here, but just to echo @UTFAPNRPT a bit, I appreciate @U90R0EPHA’s questions, feedback, and helping of other users both here in Slack and on GitHub.
Not sure if this is Calva or clojure-lsp, I am seeing often some a bit annoying auto-complete behaviour. Example:
(defn foo [{:keys [bar baz]}]
(let [v {:bar bar|}]) ; <- cursor here
I will often see my typed bar
to change to :bar
as per autocomplete, even if I didn't start the typing with a colon. It can be very frustrating because I usually type fast and accept the change, then I have to go back and delete the colon.I can generalise this by saying that sometimes local variables that come from destructuring are late to appear in the autocomplete, and probably something else takes over (that sees I have just typed :bar
and offers to be helpful.
this is what I see on Emacs, which seems to be correct, do you see in different order?
I am not sure if there are race conditions, because often times I will see this get fixed in a second attempt.
clojure-lsp sorts this to show the proper order, maybe there is client (Calva) sorting logic there?
You could confirm repro the issue and checking the client<->server logs to check if clojure-lsp returned the correct order but calva sorted
Yeah, I kind managed to repro that on emacs as well: it seems to be related with typing fast
Glad I'm not going crazy 🙂 I have turned on the diagnostics tracing here but it seems like it's not related to Calva...
hum, I think it could be related with old text on server side... kind of tricky to explain but, every change to a file, clojure-lsp update its cache to consider that file for every feature processing, and if you type too fast after the keyword, clojure-lsp will use this outdated text:
(defn foo [{:keys [bar baz]}]
(let [v {:bar|}]))
instead of
(defn foo [{:keys [bar baz]}]
(let [v {:bar b|}]))
that's why clojure-lsp suggests only the keyword, as if the code was trying to complete :bar|
That's my guess(It is especially annoying in maps in particular, as I will often hit return to go the next line, and this will accept the suggestion instead)
Feel free to open a issue on clojure-lsp with detailed repro for example that gif, it should not be easy to fix it but it helps to keep tracking
Unfortunately, the workaround is to type slower or wait a little bit before completing 😔
we could not offer completion if there are pending didChange requests, that would be a easier fix and would avoid false positives like that It would slow completions when user typed fast but provide reliable completion items
I see the didChange
request before the completion. Does that mean that the didChange
is processed async, and has not been processed at the time of the requested completion?
BTW it seems that Calva is sending the entire document to LSP on the didChange
, not sure if there's a more efficient way.
there is a more efficient way but clojure-lsp dropped that support as was causing lots of issues
I see - well, in the case of completions (and everything code-related, I think) I'd much rather being slower but accurate, vs the opposite 😄
Most of the time if I expect a completion, I pause too (since most editors have a small delay time).
> (It is especially annoying in maps in particular, as I will often hit return to go the next line, and this will accept the suggestion instead)
Possible workaround: Set editor.acceptSuggestionOnEnter
to off
.
Way too often I am at the end of a line and ready to go to the next, and some completion provider has some suggestion or other. I am much happier just using Tab
to accept, so my Enter
reliably prints linefeeds.
Thanks @U90R0EPHA - I had it set to "smart", I will try off to see if it works for me.
@U7PBP4UVA Did you open an issue for this on the clojure-lsp repo? Could you link it here if so / when you do?
@U7PBP4UVA there is a chance to have a quick fix for that, but also I'm not sure if may cause other issues so needs more testing, could you at least test if fixes your issue https://github.com/clojure-lsp/clojure-lsp/pull/1426?
Thanks @UKFSJSM38 - I'm looking for some instructions on how to run this version in Calva. Calva seems to want a command line that starts clojure-lsp - do I need to build with GraalVM or can I use the plain JVM version?
both work, for this test, it's easier just to download the binary built https://github.com/clojure-lsp/clojure-lsp/actions/runs/3788662917, it should be available to download after the jobs finish
oh, I think it's available only for linux, if you use mac, you will need to build, it's easy too, just clone the repo/branch and do a bb debug-cli
, it should build a clojure-lsp binary on project root
Hm, I must have done something wrong, I'm seeing
[Trace - 6:46:15 PM] Received response 'textDocument/semanticTokens/full - (12)' in 12ms. Request failed: Internal error (-32603).
[Error - 6:46:15 PM] Request textDocument/semanticTokens/full failed.
Message: Internal error
Code: -32603
[object Object]
on every document change - let me try with master[Error - 7:01:23 PM] Request textDocument/codeAction failed.
Message: Internal error
Code: -32603
[object Object]
[Trace - 7:01:23 PM] Sending request 'textDocument/semanticTokens/full - (217)'.
[Trace - 7:01:23 PM] Received response 'textDocument/semanticTokens/full - (217)' in 8ms. Request failed: Internal error (-32603).
[Error - 7:01:23 PM] Request textDocument/semanticTokens/full failed.
Message: Internal error
Code: -32603
[object Object]
[Trace - 7:01:23 PM] Sending request 'textDocument/documentSymbol - (218)'.
[Trace - 7:01:23 PM] Received response 'textDocument/documentSymbol - (218)' in 6ms. Request failed: Internal error (-32603).
[Error - 7:01:23 PM] Request textDocument/documentSymbol failed.
Message: Internal error
Code: -32603
[object Object]
[Trace - 7:01:24 PM] Received notification 'clojure/textDocument/testTree'.
[Trace - 7:01:24 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 7:01:24 PM] Sending request 'textDocument/codeAction - (219)'.
[Trace - 7:01:24 PM] Received response 'textDocument/codeAction - (219)' in 6ms.
[Trace - 7:01:24 PM] Sending request 'textDocument/documentHighlight - (220)'.
[Trace - 7:01:24 PM] Received response 'textDocument/documentHighlight - (220)' in 2ms.
[Trace - 7:01:25 PM] Sending request 'textDocument/codeAction - (221)'.
[Trace - 7:01:25 PM] Received response 'textDocument/codeAction - (221)' in 8ms.
2022-12-27T17:00:11.442Z ERROR [clojure-lsp.server:55] - Error receiving message: Internal error (-32603)
{:id 20, :method "textDocument/codeAction"}
[37mjava.util.concurrent.ForkJoinWorkerThread.run[m [32mForkJoinWorkerThread.java: 177[m
[37mjava.util.concurrent.ForkJoinPool.runWorker[m [32m ForkJoinPool.java: 1806[m
[37mjava.util.concurrent.ForkJoinPool.scan[m [32m ForkJoinPool.java: 1840[m
[37mjava.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec[m [32m ForkJoinPool.java: 1311[m
[37mjava.util.concurrent.ForkJoinTask.doExec[m [32m ForkJoinTask.java: 387[m
[37mjava.util.concurrent.CompletableFuture$AsyncSupply.exec[m [32m CompletableFuture.java: 1760[m
[37mjava.util.concurrent.CompletableFuture$AsyncSupply.run[m [32m CompletableFuture.java: 1768[m
[33mpromesa.util.SupplierWrapper/[1;33mget[m [32m util.cljc: 21[m
[33mpromesa.exec/wrap-bindings/[1;33mfn[m [32m exec.cljc: 147[m
[33mclojure-lsp.server/fn/[1;33mfn[m [32m server.clj: 298[m
[33mclojure-lsp.handlers/[1;33mcode-actions[m [32m handlers.clj: 413[m
[33mclojure-lsp.handlers/[1;33mwait-for-changes[m [32m handlers.clj: 67[m
[37m...[m [32m [m
[1;31mjava.lang.IllegalArgumentException[m: [3mNo matching method sleep found taking 1 args[m
I don't think it's a bug since both tests and integration-tests are passing and I'm using a nightly build all the time
since it happens for you on master as well, sounds like some other weird thing in your env, maybe java version?
Indeed
(Thread/sleep (* 1.2 200)) ;; fails
(Thread/sleep (long (* 1.2 200))) ;; works
Yep, adding a cast to long works . I need to go make dinner but I’ll test again later.
It seems to fix the issue @UKFSJSM38 - I will need a few days working with this in "production code" if you want more real-life testing though.