@U0AD3JSHL As @U0183EZCD0D said, these will have to be configured in your project.clj or deps.edn file, otherwise Cursive will un-mark them on every sync.

If you don’t want them added by default, you could have the paths in an alias/profile, and just use that when syncing with Cursive.

I have a similar problem with a project set up similar to ring - a parent project using lein sub with a series of subprojects , used to all load and resolve fine in cursive but last few versions it never remembers/sets the source roots, and gets confused with the checkouts/

@U0HJCPF3J Is your project something I can look at, or are you able to set up a simple test repo in a similar config?

you can see the behaviour with the main ring project (i.e just check out https://github.com/ring-clojure/ring and open up the top level project) , my project is configured identically with lein sub and a series of sub projects

I do remember that happening but I just tried command-clicking on a defresolver in a clj namespace and cursive navigated correctly to the definition. :man-shrugging: I’ll keep an eye open for when it happens again.

That is correct, I guess resources/public/js/ is on the classpath. Which I actually want, since I use the classpath to serve the JS when requested by the browser.

Removing the js output from the classpath results just in Cmd-click on the namespace not doing anything (just telling me "No usages found..."). The referred var still cannot be resolved.

pathom is always on the classpath since shadow-cljs uses it internally 😉

Ah, that explains it. Thank you!

How would you like this to work? I’m not sure how Cursive would use these.

it helps in so far that if you integrate clj-kondo linting inside Cursive then people would see the correct warnings

but I can imagine this would be a big step and doesn't integrate with the way IntelliJ works

> How would you like this to work? It's a good question. I'm not very familiar with with konfigs - I am assuming there is enough information to determine the "source" of a symbol/keyword and, thus, that would be enough information to wire up Intellij's Find Usages feature.

> but I can imagine this would be a big step and doesn't integrate with the way IntelliJ works Thanks. I guess it was more wishful thinking than anything else 🙂

I still don’t quite understand. As I understand it, the clj-kondo integration should show the warnings in the editor already, right? And when there’s a warning in the editor, you should be able to use the normal Cursive find usages feature at that point?

> As I understand it, the clj-kondo integration should show the warnings in the editor already, right? This is correct. The other point seems logical too.

But Cursive also emits syntax warnings on its own.

And these are not informed by any clj-kondo configuration

And that was what the question was about: could clj-kondo configuration inform Cursive's own understanding of the syntax, somehow

So is the proposal to control the IntelliJ inspections via the clj-kondo config, i.e. enable and disable the roughly equivalent inspections based on the config? Or to somehow use the clj-kondo analysis results?

I don't think anyone has made a proposal, Mark was just asking about thoughts. I don't have any thoughts on this, but I would be open to help you out with something, if you needed it from the clj-kondo side.

Ok, I’ll wait and see what Mark suggests. I’d be interested to know what the issue around attribute keywords is, for example.

Well, the config for pathom3 is pretty basic: https://github.com/wilkerlucio/pathom3/blob/master/resources/clj-kondo.exports/com.wsscode/pathom3/config.edn I think the same can be accomplished in Cursive with "resolve macro as" if I remember correctly.

Ah, ok, yes, that should be easy.

What issue are you having? You need to have ports open, but what I've found useful to do is just use repl within wsl, so for example lein repl then connect to the nrepl port from cursive using the remote repl option 😃...

thanks!!