Clojurians Log v2

what tricks do people have for cursive when you have macros that generate a bunch of symbols? I know you can teach intellij in simple cases as described here: https://cursive-ide.com/userguide/macros.html

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

I wonder if it would be useful/practical to have something like the following:

;;@resolve with-my-wrapper :as let
(defmacro with-my-wrapper [bindings & body]
  ,,,)

(with-my-wrapper [foo bar]
  (do-stuff))             ;; <-- Cursive now knows to treat this like a `let` expression

Kind of like Java annotations, except it would be IDE-specific and wouldn’t affect how the code actually runs. Cursive would just check comments for a leading ;;@resolve and then do the same thing as when you select Resolve As via the GUI.

Pros: automatically configures Cursive correctly when sharing code; alternative to generating stubs; avoids needing to regenerate stubs for same source

Cons: ???

I have a clojurescript project that when I open in IDEAJ and Cursive on my linux box it all works fine, but when I open it on windows it yellow underlines everything: What could I be missing between my linux install and windows install? It builds and runs fine, hot-realoading works etc. It's just cursive doesn't seem to like it. On Linux I do shadow-cljs pom to create the pom.xml and load that as the project file, did same on windows and it made no difference.

@cfleming bug report. If deps.edn has a map with extra keys, then cursive complains about The following errors were found during project resolve: /path/to/deps.edn: <http://repo1.maven.org|repo1.maven.org>: nodename nor servname provided, or not known. Example broken edn

'{org.clojure/clojurescript {:mvn/version "1.10.844"
                               #_:git/url "<https://github.com/clojure/clojurescript>"
                               #_:sha "3fdaabedb1343f434b6cb4f75fa28e748f96eff0"
                               #_#_:local/root "/Users/mk/Downloads/clojurescript/"
                               #_#_:local/root "/Users/kommen/work/clojurescript/"}}
#:org.clojure{clojurescript {:mvn/version "1.10.844", "<https://github.com/clojure/clojurescript>" "3fdaabedb1343f434b6cb4f75fa28e748f96eff0"}}

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?

- 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

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.

#_ only comments the very next form, so it ended up being a map with key "<https://github.com/clojure/clojurescript>" 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.