Clojurians Log v2

I just looked at Calva for the first time in a while, it's amazing how many improvements were made in the meantime! One somewhat distracting "new" behaviour I noticed though - the "quick fixes" lightbulb is being triggered for basically everywhere, suggesting that I change collections to vectors/maps or cycle the privacy of defs. Where is this coming from and can I disable it on a per-rule basis? Some refactorings like "move to let" are useful but others just create unnecessary noise and clutter on a default config.

Those are code actions that come from clojure-lsp, they are suggestions and there is no opt-out ATM. it's pretty common to return all available code actions and user decide if use or not, if you want important code actions only, VSCode will show a different color for the ones clojure-lsp qualify as important for that code like add missing require

One thing I notice though @brandon.ringe is that calva is suggesting the resolve macro as even if does not has support yet

You may want to ignore that action or implement it maybe

I see, thanks for the info! I just found it a minor annoyance more than anything, like a notification counter that won't go away.

Sometimes the lightbulb also obscures the actual text, although that's probably a VSCode issue rather than Calva's

New Calva version, v2.0.184 just released, with these changes: • Fix: https://github.com/BetterThanTomorrow/calva/issues/1086 • Fix: https://github.com/BetterThanTomorrow/calva/issues/1060 • https://github.com/BetterThanTomorrow/calva/issues/1088 and bump to `2021.03.30-20.42.34` • https://github.com/BetterThanTomorrow/calva/issues/1091

Hey guys. It seems that although the jack-in command was working for me a few days ago, VSCode now tells me Ctrl + Alt + C, Ctrl + Alt + J is "not a command". Further probing reveals that the command does not appear in the command palette when searched for. I also found this thread where @pez dealt with the same (or a similar) thing some time ago so I thought he or another might recall the solution. https://github.com/BetterThanTomorrow/calva/issues/287 I tried installing the versions from 3 and 6 days ago to see if it had anything to do with the update, but no apparent difference. Worth making a help report, or maybe I'm missing something? Thanks – on the brighter side, loving this plug-in so far.

Are you in a Clojure project when attempting jack-in?

Tried both with a Clojure project open and without one open; same result.

Is the shadow-cljs + deps.edn jack-in option known to be broken? I can’t quite get it working. No error messages, no logs, it just hangs at nREPL server started on port… and the output REPL buffer never drops into a prompt. My http server needs to be started by running (go) in the clj repl, but I can’t get that far, which means I can never load my cljs code in the browser to get that runtime connected either. :thinking_face:

Hang on . . . It was only the file that was open.

With the folder open, seems to work.

Thank you!

Yeah, needs a folder. That’s where the Standalone REPL comes in. Glad you got it working!

Good Friday, Calva-friends 😃 https://twitter.com/pappapez/status/1378039453122498561

It could be broken… Have seen a bit of trouble with it. Yesterday there was someone, (@alpox?) who posted about a setup using a deps.edn alias instead. I will have a look at deps.edn + shaodw-cljs tomorrow to see if it is the implementation or the documentation that is broken.

I just got it working! I used the custom :watch alias in deps.edn documented in this issue here: https://github.com/BetterThanTomorrow/calva/issues/1032

I’m also using datomic dev-local like the user in this issue, so that might have been part of it? Not sure.

I also restarted VS Code and that seemed to shake something loose. There was an update at the exact same moment, so it might have just been terrible timing 🙂

Anyway, thank you for Calva 🙏 , it’s a really great tool

Glad it is working! If you see how the http://calva.io documentation could be improved, please file an issue and/or PR.

I did the same thing due to likely the same issue ;)

Given the following snippet of code:

(defmulti foo :bar)
(defmethod foo :test
  [{:keys [a b] :or {a 1 b 2}}]
  (let [q (* 10 (dec a))]
    (+ b q)))

i.e., the warnings are in {a 1 b 2} not on the keys part — what does this warning even mean? “unused default”

Funnily enough the warning goes away when you change it to defn:

(defn foo
  [{:keys [a b] :or {a 1 b 2}}]
  (let [q (* 10 (dec a))]
    (+ b q)))

@seancorfield unused default means that that code doesn't have any meaning because the binding for which you introduced the default was never used

instead of "unused binding" it says that, because you're not really introducing a new binding there

@pez I think it would be useful if Calva printed the contents of CLJ_KONDO_VERSION at startup (this is available in the classpath) so people know what they are using

@seancorfield you can also try enabling the clj-kondo standalone vscode plugin and disable calva linting, to see if that makes a difference

@seancorfield see #lsp, it seems something specific with this

Joined. Thanks.

Startup of Calva itself, right? We currently have the "LSP Server Info" command which shows the kondo version being used by lsp. Do you mean this?

oh I didn't know this, thanks

I heard it's possible to update clojure-lsp separately from calva, how does one do this? I don't find the info here: https://calva.io/clojure-lsp/#troubleshooting

Oh, I see. In the extension settings

@seancorfield Tomorrow when @ericdallo creates a new lsp version you can upgrade it here:

Ah we need to add that setting to the docs. Thanks

Oh wow, good to know! Thank you!

https://github.com/BetterThanTomorrow/calva/pull/1089 ¯\(ツ)/¯

😃