Glad to hear this!

You are welcome, @UG00LE5TN ! Thanks for letting us know about this.

I just restarted the bloody thing 😄

It could have been Calva causing this. Did you check the dev console for any clues?

Even with everything disabled?

Depends on wether you had reloaded the VS Code window after disablement. That requires a reload to take effect.

Yes, VSCode has actually an option to "reload without extensions"

"Developer: Reload with Extensions Disabled"

Even that. If you had reloaded the window with Calva disabled, then Calva is not causing the behaviour.

There's also an option to bisect extensions, btw.

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.

It must have been weeks of uptime.

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.

(But, yes, I can ignore that blue dot for quite a while. 😃 )

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!)

Since you start the REPL yourself. A reload is quite cheap.

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.

No, not possible. Have a look at the Error Lens extension and see if that can mitigate this a bit for you.

It does, thanks

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

Deleted some messages because I was confused about which thread this is. 😃

Anyway, no, I don't think Calva can affect this.

I could be wrong though. It is hover providers at work, if someone wants to investigate it.

Would it be worth filing an issue?

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. 😃

https://github.com/BetterThanTomorrow/calva/issues/1998

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.

https://github.com/BetterThanTomorrow/calva/issues/2001

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?

Looks like so:

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.

Disable automatic parameter hints?

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.

@U90R0EPHA I love you!

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.

is it missing a } on purpose after bar?

No, I am just tired and editing in Slack 🙂 fixed

np, this probably comes from clojure-lsp

especially if no repl connected

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.

Hum

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

Here's what I see

If you see, the first attempt, I don't even see the local var

Yeah, I kind managed to repro that on emacs as well: it seems to be related with typing fast

where clojure-lsp does not consider the local, only the keyword

kind of hard to repro again, not sure why it happens tho

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|}]))

(defn foo [{:keys [bar baz]}]
  (let [v {:bar b|}]))

(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.

yep, it's complety async for performance reasons

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 😄

yeah, and it should not be that slow too

Most of the time if I expect a completion, I pause too (since most editors have a small delay time).

I will open an issue tomorrow, with a fresh namespace and the logs too.

Have a nice evening!

And, thanks!

Thanks!

> (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?

https://github.com/clojure-lsp/clojure-lsp/issues/1425

Thanks @U9A1RLFNV

Thank you

@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

I will try

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]

I'm seeing the same on master

Hum, you are probably not building it properly or something

check server logs

https://clojure-lsp.io/troubleshooting/#server-log

Other things work though?

[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

that's weird :thinking_face:

I see it for textDocument/semanticTokens/full and textDocument/documentSymbol

No matching method sleep found taking 1 arg

we didn't change anything recently on those, that's odd

in codeAction too

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?

I'm using Java 17 (I think)

Actually 19

I didn't test with java 19 yet, I suggest use 17

I see that Thread/sleep accepts long but it's being multiplied by 1.2

yeah, maybe something we need to fix for java 19

Indeed

(Thread/sleep (* 1.2 200)) ;; fails
(Thread/sleep (long (* 1.2 200))) ;; works

I'll try an easy fix

thank you!

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.

Sounds great, thank you!

I'll still do some internal testing too

(Amazing how the fix is just wrapping with an existing macro!)

yeah that macro means "wait for any change that you are still doing", it's something that makes sense for some cases but may cause the processing queue to increase, not sure why completion was not using it, but probably makes sense