Subscribing to this. I am unaware of a way to do this now.

https://www.youtube.com/watch?v=kt4haSH2xcs

not the answer you are looking for probably but disabling all "unresolved symbol" warnings works for me 😉

also, https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md

thanks I'll have a read of that. btw There was a bit of discussion in the recent defn cast about kondo and cursive and the overlap in some bits of functionality

Thanks, I'll look that up

One thing that’s not documented yet is the new Resolve as: None which will disable the warnings locally inside that macro form. This works well for DSL-style macros which define a lot of local symbols, but doesn’t help for macros which define global var-style ones.

- how would u "annotate" 3rd-party libs? fork them and use :git/url, instead of :mvn/version? - how about closed source stuff, like datomic, where u only have access to the AOT compiled class files? - as u said, it's an IDE-specific solution; it wouldn't work with most teams, because they are typically not homogenous editor-wise. - using comments is a horrible hack, as we saw in other instances, like javadoc. it

- it's also not easy to process programmatically, because u would need to write a character level parser for the comment strings, as opposed to using the already existing clojure parser - u r also losing reflection capabilities, so for example editor tooling can't query a running clojure process about these formatting settings

There are some suggestions of things to check here, does that help? https://cursive-ide.com/userguide/eap/troubleshooting.html#help-lots-of-symbols-don-t-resolve

note that :git/url and :sha only have one #_ so the https line is not commented, neither the value of the sha itself

putting #_ #_ fixed everything 🤷

why the shrug emoji? is it not clear why do u need 2 #_ forms?

#_ only comments the very next form, so it ended up being a map with key "" and value "3fdaabedb1343f434b6cb4f75fa28e748f96eff0" - not sure how that's parsed

i.e. :git/url and :sha are the only things commented out

(in the first two lines)

That’s right - that’s what helios’s original comment shows at the end, the resulting map. Oddly, deps itself accepts this so I’m not sure why it would fail with Cursive since Cursive is getting that error back from deps. I’ll try to reproduce this and see if I can figure it out.

Interestingly, even though the CLI doesn’t produce an error, it doesn’t produce the right result either:

~/d/c/helios-deps-problem> cat deps.edn
{org.clojure/clojurescript {:mvn/version "1.10.844"
                               #_:git/url ""
                               #_:sha "3fdaabedb1343f434b6cb4f75fa28e748f96eff0"
                               #_#_:local/root "/Users/mk/Downloads/clojurescript/"
                               #_#_:local/root "/Users/kommen/work/clojurescript/"}}⏎
~/d/c/helios-deps-problem> clojure -Stree
org.clojure/clojure 1.10.3
  . org.clojure/spec.alpha 0.2.194
  . org.clojure/core.specs.alpha 0.2.56
~/d/c/helios-deps-problem> clojure -Spath
src:/Users/colin/.m2/repository/org/clojure/clojure/1.10.3/clojure-1.10.3.jar:/Users/colin/.m2/repository/org/clojure/core.specs.alpha/0.2.56/core.specs.alpha-0.2.56.jar:/Users/colin/.m2/repository/org/clojure/spec.alpha/0.2.194/spec.alpha-0.2.194.jar

I’d have expected it to pick up clojurescript and just ignore the map entry it doesn’t understand. @U064X3EF3 might know why that is.

#_ is not valid edn

And deps.edn is read with the the edn reader

Not sure if that’s a clue

Oh, interesting, I had forgotten that. Shouldn’t that produce a read error then?

Actually I’m wrong!

The discard sequence is part of edn

I don’t recognize that error, don’t know what that is

Ok, I’ll try to debug this later and report back.

@U0AD3JSHL I’m not seeing an error with this. Cursive imports without the CLJS dep but that’s because Deps doesn’t return it, as detailed above. I’m using CLI tools 1.10.3.810.

That error seems to be something to do with ssh. Do you have something in your user deps file which might cause deps to do something with ssh? The most likely candidate would be something with git and the new git shell integration, but that’s getting outside the realms of my deps CLI knowledge.

The error was about Maven so that doesn’t match up

That deps.edn above is wrong - missing the outer map with :deps key

in the original message the map had a quote, so i assumed it wasn't the whole deps.edn

Ugh, you are absolutely right, I’m not paying attention. If I add the outer map and :deps, both Cursive and CLI do the right thing. I can’t repro the initial error.

yes, sorry, it wasn't the whole deps.edn 🙂

was just the culprit part of a larger deps.edn that worked fine