Clojurians Log v2

https://twitter.com/CursiveIDE/status/1305737573004795904

@kenny This includes the protocol name resolution fix.

Cheers @cfleming, stub generation works now! :thumbsup:

does “structural selection in let” mean semantic highlighting in let binding vector? ah, never mind. it’s what i thought it is, which is awesome! 🎉 i noticed the github issue has a comment that has a request for the same behavior for map literals. will this work there as well?

Just asking is this even possible in IDEA/Cursive (not implemented yet, I'm aware) - to customize IDEA to pretty print various content types (say application/edn) in HTTP responses.... Currently JSON gets pretty printed, but EDN not:

GET <http://localhost:8080/api/scrambled?s1=abcorldwbh&amp;s2=worldz123>

HTTP/1.1 400 Bad Request
Date: Tue, 15 Sep 2020 05:57:27 GMT
Content-Type: application/edn; charset=utf-8
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: *
Content-Length: 456
Server: Jetty(9.4.28.v20200408)

{:spec "(spec-tools.core/spec {:spec (clojure.spec.alpha/keys :req-un [:spec$6285/s1 :spec$6285/s2]), :type :map, :leaf? false})", :problems [{:path [:s2], :pred "(clojure.core/fn [%] (clojure.core/re-matches #\"[a-z]*\" %))", :val "worldz123", :via [:spec$6285/s2 :my-clojure-demo.api/only-small-letters-spec], :in [:s2]}], :type :reitit.coercion/request-coercion, :coercion :spec, :value {:s1 "abcorldwbh", :s2 "worldz123"}, :in [:request :query-params]}

I find using IDEA's HTTP request support nice - similar to curl/httpie/postman, probably weaker than some, but nice to have everything in one place, no context switching

(btw, also found that most of IDEA users are barely aware of it existing)

Could you share your run configuration settings in Cursive? I can't make it work with starting the repl from inside IntelliJ

@cfleming has the matching paren highlighting changed? I've upgraded from a goodness-knows-how-old version of cursive to the latest, and keep hitting newline on the wrong paren now - it's like it used to match on the paren before the caret, and now it highlights based on the current paren?

@cmdrdats Can you show a screenshot of what you mean? I’m not seeing what I think you mean here, but I might be wrong.

So, in this case, I (think I) expected the highlight on the paren by the + instead of fn

the only reason I noticed this is because I'm suddenly getting it wrong very consistently

oooh

if I change away from block caret, it acts correctly :mindblown:

I was just going to ask where your caret was 🙂

must be an intellij weirdness?

Maybe, I’ve never used the block caret, so it’s not clear to me exactly where the caret is. I would assume that screenshot is the equivalent of having the caret before the final paren, but you’re right that that highlighting makes it look like it’s after it.

ye, the actual 'position' of the caret on block caret is to the left of the block - I assumed this was just a display thing :rolling_on_the_floor_laughing:

but cool - I'm happy to just switch to pipe caret - it sorts the issue out!

Yes, my official recommendation is Don’t Do That.

:rolling_on_the_floor_laughing:

thanks for the feedback 🙂

After updating cursive a few minutes ago, datomic stuff looks a little weirder (i have generated stubs):

although i can imagine that those things can't be resolved by cursive, it makes all my queries look like something is wrong

(intelij 2020.2, latest cursive 1.9.4-eap4, JDK 11 through Graal)

Have you your stubs generated?

Ah ai see you do, nvm

Invalidate caches?

done both, no avail

After updating to the latest Cursive (1.9.4-eap4-2020.2), my monorepo style project will continuously ask me to generate stubs for a project. It appears to want to generate stubs for many of the modules in this project. If I keep clicking "Generate now," it'll eventually stop asking. It seems like instead it should ask me to generate stubs for all projects.

Also, after updating to the latest, all (defs in a comment block are now marked as cannot be resolved. Example in the below screenshot.

I can confirm I see the same issue

Also Datomic queries all are marked as unresolved even though they are quoted.

Another one. I assume these are probably all the same issue.

Applying Cursive's auto-format will move the commented out datomic.client.api require too far to the left. Previously it would keep it indented to align with the first datomic.client.api require.

Yeah same here^.

All quoted/commented symbols are now marked as “unresolved.”

At some point Cursive changed how Parinfer works w.r.t. to opening a new form. It used to be the case that opening a new parenthesis would add a matching paren at the end of the parent form, e.g., given:

(+ 1 2 3)

(+ (1 2 3))

(+ () 1 2 3)

Sorry about the quoted highlighting folks, I’ll fix that today.

Yes, I think I’ll need to make this configurable. I’ll do that for the next release.