Amazing!

That cycle-fn-literal is sweet

Could I go over something, is this no longer valid? #_{:clj-kondo/ignore [:clojure-lsp/unused-public-var]}

I'm getting a diagnostic hint that the function below it is not used

This should still be valid

Not anymore it appears

yeah, I confirmed the issue

Before I wasn't getting the hint warning. Trying out the new version before pushing to arch and it's now flagging this

okaydokey

let me take a look

np

I know what it is, will open a new thread

kk

or, just tranfserr to github issue

np

Done @U11EL3P9U

sweet, having a looksee

Yup, all good

good, thank you!

you're most welcome! Thank you for fixing it quickly 🙂

@U04V15CAJ @U11EL3P9U reported that

#_{:clj-kondo/ignore [:clojure-lsp/unused-public-var]}
(defn foo [a]
  1)

will do a quick fix making it async so we can fix it on clj-kondo later carefully

Well, is not that easy to fix that on clojure-lsp, so @U04V15CAJ I know you are busy with the windows issue, so I could try to fix it on clj-kondo, the issue seems to be that reg-finding https://github.com/clj-kondo/clj-kondo/blob/master/src/clj_kondo/core.clj#L205 doesn't handle-ignore properly

so not sure how we could fix that behavior

I think this used to work by luck on clojure-lsp because we async lint that not using reg-finding before

Oh, sorry, the issue seems on clojure-lsp side, clj-kondo there is even a test for that, I think I found the issue, will work on a fix

@U11EL3P9U could you try changing your .lsp/config.edn :linters :clj-kondo :async-custom-lint? to false ? or just try latest #clojure-lsp-builds

I think with recent changes and improvements we don't need that flag anymore, but for now will do a quick fix changing that flag default to false

Releasing the fix...

Hi. Just back

Yup, changing that setting to false restores behaviour

Good, the release is almost done

np

@UKFSJSM38 is this something you’d like help with? Or do you have it handled?

@jacob.maine for now it's fixed, but we should either remove async-custom-lint? or make it work without those issues, with the improvements we have, we could probably remove it, but I'm afraid huge files with lots of var-definitions could be affected

Yeah, I figured you’d left it in place for really huge files. When you have a chance, will you explain why making it async fixes things? I don’t really understand how reg-finding! works differently in the sync and async versions

Actually, before the huge performance improvements I did that custom linter be async, which doesn't block the rest of lint, that worked and was helpful until we fix performance with this release, now it's not necessary, the code is complex and now causes this bug :), so maybe removing makes sense, we jsut need to make sure the performance is still good for huge files with multiple definitoins and references

Gotcha. If we can remove it that’d be ideal. If not, I’d like to understand how things work. To be honest I’ve never understood how reg-finding! works with an async custom linter. How does clj-kondo know the custom linting is done? My working hypothesis has been that reg-finding! actually doesn’t matter when the linter is async. Instead of waiting for clj-kondo to return us back our own findings, we publish them straight to the client. Is that right?

You can do anything you want in the custom-lint-fn, reg-finding will just take care that whatever you do there will be part of the :findings returned by clj-kondo itself

but if you're not going to use those, then you don't have to call reg-findings! there of course.

so you could launch an async thread/future/whatever in the custom-lint-fn and just do your own thing with the analysis

@U04V15CAJ I imagine that if you call reg-findings! asynchronously, it’s too late for those findings to be included in clj-kondo’s analysis… clj-kondo will already have returned, right?

that's true

That’s what I figured. Just wanted to be sure.

but you could trigger the updating of clojure-lsp's idea of findings in there

you will just have to keep track which are the most recent / valid findings yourself

> trigger the updating of clojure-lsp’s idea of findings

Yeah, I think that’s what clojure-lsp is doing, or at least what it’s intended to do. This bug suggests maybe that isn’t really working

e.g. using a correlation id or so

That's what clojure-lsp used to do when async

Right… there are lots of subtle timing bugs we haven’t quite worked out

Yes, IMO doing it sync is way easier and less error prone

now it's super fast right?

Yes!

Definitely, but in the case of your giant Nubank file, which still takes 5 seconds, I can imagine that it’d be nice to start other things like symbol highlighting before the linting is done

Actually, it takes 3s the whole project, I'll test the biggest file to make sure it's still fast

Symbol highlight before lint is dangerous, we may show outdated highlight, we need to wait for kondo analysis to reliable show that

Gotcha. Maybe that’s a bad example

As I’m testing this stuff I keep adding and removing duration logs around custom linting for a single file. Maybe we should add them temporarily until this feature has settled.

Just out of curiosity, what are you using for getting the minibuffer stuff in this position?

My setup is neovim + coc + conjure and coc-clojure. You can find it all here . Enjoy!

yes, probably related with recent changes c/c @U0BUV7XSA

yup, got a fix for that on the way

you guys are super awesome! Anyhoooo, off to bed, ttfn!