Maybe it can be some stale clj-kondo caching? See if it helps to stop clojure-lsp, wipe .clj-kondo/cache, then start clojure-lsp again.

Hmmm. I tried that and it didn’t help. I found an example within the same file where one reg-event call is okay, and the other reports warnings.

I did notice, experimenting, that if I use reader ignore form (#) on the event name (for example: #::display-edit) then it suddenly is okay again. Of course, I do need that event name, so I can’t leave it commented out.

Could be something to report in #clj-kondo which is what Calva is using for this. See if you can reproduce using the clj-kondo command line tool.

At the command line clj-kondo reports no errors for the file.

Calva reports the clj-kondo version it uses. Is it the same as the one you used on the command line?

I was just checking that. So on the command line (I installed clj-kondo with brew) it is 2022.03.09. Calva is reporting 2022.03.10-SNAPSHOT. So different versions.

I tried but didn’t have much success installing 2022.03.10-SNAPSHOT on the command line.

Ask in #clj-kondo how to find it. @U04V15CAJ usually makes builds of his tools super accessible.

👋 This is clj-kondo from master. You can try it like this:

clojure -Sdeps '{:deps {clj-kondo/clj-kondo {:git/url "" :git/sha "2cc9777752d9f54ed91baa4c6ddaa0c2b8812049"}}}' -M -m clj-kondo.main --lint ...

with the right SHA in place

So I can’t see a branch or tag for “2022.03.10-SNAPSHOT”. How do I find the SHA for that?

I’m just looking around in github. I’ll clone it and look more closely…

you can't :) but you can find the SHA of clojure-lsp and look which clj-kondo version they used

and then use that exact version

which clojure-lsp version are you using?

and is it possible to share this code or a reproduction so I can try it locally?

there has been a chance to re-frame linting. /cc @U0508JT9N

Yep, I can repro it like this:

(ns dude (:require [re-frame.core :as re-frame]))

(re-frame/reg-event-fx
 ::setup
 (fn [_ [_ {show-key :show-key}]]
   {:fx [[:dispatch [:path show-key]]]}))

Will post an issue and fix it.

For now you could use a #_:clj-kondo/ignore annotation until the next release

Thanks @U04V15CAJ. Not sure if you still need this info, but this is what Calva prints out regarding versions:

clojure-lsp version used: 2022.03.26-18.47.08
clj-kondo version used: 2022.03.10-SNAPSHOT

OK, so this is how you can find out which clj-kondo version it is, navigate to the release. Then select the commit. Then select browse files: https://github.com/clojure-lsp/clojure-lsp/tree/323bfabf585f0cc933ce6b1b87809f7a3597eb5d

Then you arrive at lib/deps.edn here: https://github.com/clojure-lsp/clojure-lsp/blob/323bfabf585f0cc933ce6b1b87809f7a3597eb5d/lib/deps.edn

And then you can see it's version 2022.03.10-20220323.200333-13

https://github.com/clj-kondo/clj-kondo/issues/1637

>

clj-kondo version used: 2022.03.10-SNAPSHOT

function sayClientVersionInfo(serverVersion: string, serverInfo: any) {
  const cljKondoVersion = serverInfo['clj-kondo-version'];
  const calvaSaysChannel = state.outputChannel();
  calvaSaysChannel.appendLine('');
  calvaSaysChannel.appendLine(`clojure-lsp version used: ${serverVersion}`);
  calvaSaysChannel.appendLine(`clj-kondo version used: ${cljKondoVersion}`);
}

It would be nice if clojure-lsp reported the non-SNAPSHOT version

yeah, there is a TODO for that

Ah, thanks for asking that @U9A1RLFNV. I got confused but thought I just must have missed something. 😃

Where’s it getting that snapshot version from? Just curious, as I don’t see it in the deps.edn @U04V15CAJ pointed to.

clj-kondo has a file called CLJ_KONDO_VERSION on the classpath which has SNAPSHOT on in-between releases

I have suggested in the past that lsp should overwrite that file with their fully qualified non-SNAPSHOT version

when building

sounds a little bit tricky, maybe we could make kondo return/have that somehow

that is not possible since that version you're using is not known before clj-kondo deploys to clojars

but you know that version so you should overwrite the file or have some other means to give Calva that version number :)

yeah, sounds a little bit odd to me we need to manually do that

you would not have to do this manually if you automated it

yeah but I mean, we are automating knowing the version of a external lib, IMO the external lib should know its version right?

maybe CI could receive that from top, so clj-kondo could know this before

I already explained why that's not possible

but once again: if you deploy a SNAPSHOT to clojars, it does get assigned such a "date" suffix

but you don't know this suffix in advance

you could also use clj-kondo as a git dependency and report the SHA. Whatever works.

> you would not have to do this manually if you automated it 😂

I see, still sound to like we are fixing a thing clj-kondo should return somehow, maybe have do not use SNAPSHOT but a commit count or something else

It's unusual that libraries report their clojars version as part of their artifact. I've already done more than I should have by including this file. You're including this dependency so ultimately you know the version you're using. :P

We could include the SHA as part of the artifact but this would create a difference with git deps.

well, this looks something would need to be fixed on clojars or change the way clj-kondo release snapshots which sounds lot of work So I think we would need to do this on clojure-lsp, feel free anyone who wants to give a try

Or clojure-lsp should just never use a SNAPSHOT version, that's also an option

Is it possible to include the SHA of a commit in a pre-commit hook? I guess not, so that's a bit hard to get right in all cases

yeah, maybe use the date? something like

VERSION=$"$(date -u +"%Y.%m.%d-%H.%M.%S")"

but that still wouldn't get you the exact commit

yes

So hopefully you by now understand why I suggested what I suggested a few times already 😂

Which is: include the same mvn version you're using and overwrite the CLJ_KONDO_VERSION in your jar which you use to build your binary/jar

yeah, little bit ugly but easier indeed

"Not everything is awesome" - Rich Hickey

back to the bug in question. it seems that it shows its face only when analysis and linting is done in one go. which makes sense for lsp i guess

I've been thinking, I could update the CLJ_KONDO_VERSION before lsp wants to do a release so it will be available on clojars, without doing an "official" clj-kondo release perhaps, which includes the binary version and lsp version. I'm willing to try this until I experience problems with this approach.

@U0508JT9N yes, that is very common. also, when linting says there are unresolved symbols, it's very likely the analysis is plain wrong too with respect to locals

my point is that I *think* this only breaks linting if it is run with re-frame analysis

yes, could be, but lsp also uses that I think?

either way, it should not break anything :)

I think the bug was that analysis happens without the locals being in scope

maybe the safest is to just get the relevant keyword out, register that and then let clj-kondo analyze the whole expression as always

yeah that or dbl analysing (and some locals not being avail at the re-frame analysis stage). yeah my fix is along those lines, still wip

@U04V15CAJ you want to try the CLJ_KONDO_VERSION right now before I release a new lsp version today?

sure, how?

@UKFSJSM38 I've been thinking also, how does Calva get clojure-lsp's version at startup?

from clojure-lsp serverInfo/raw command which clojure-lsp just get from https://github.com/clojure-lsp/clojure-lsp/blob/master/lib/src/clojure_lsp/kondo.clj#L17

clojure-lsp's version

oh, the same way: https://github.com/clojure-lsp/clojure-lsp/blob/master/lib/src/clojure_lsp/shared.clj#L377

@UKFSJSM38 ok, maybe you could just write another file instead of overwriting and use that one

maybe, I'll leave it for next release so

FYI will use latest clj-kondo master version for this one

ok, please go ahead

Released!

Sounds like clojure-lsp might have either not started or is misconfigured or something. Try stop/start it via the statusbar item (or the Calva commands). If that doesn't help, try stop it and wipe .lsp/ and .clj-kondo/ caches and then start again. If this doesn't help I suspect a config error. When was the last time it worked?

Ill try that thanks. I havent coded since last week, so a week ago.

Thanks for reporting back. I don't think anything has changed during that week that should cause this.

Do you want to call c/quick-bench with some <code>, or do you want a quicker way to type (c/quick-bench <code>)?

Was looking for the latest, but the former will do too, whatever is easier

At least I know how to do the former. 😃 A custom repl command should do the trick https://calva.io/custom-commands/ With a snippet like (c/quick-bench $current-form)

Didn’t know about custom repl commands, thanks that’s really useful 👌

lein new app clojure-noob! Then you can go to VS Code, and "open the folder" which contains your new project's project.clj.

What @U0HG4EHMH says. Even lein new app clojure-noob && code clojure-noob. That said, this is lacking from the material we so far have. We should fix that.

Got it, thanks. I installed Leiningen and got it to work.

Also, couldn't I run those commands in VS Code's Terminal after I open my project folder? It will be in the proper folder anyway.