Fork me on GitHub
#cursive
<
2021-07-01
>
nodename02:07:05

I’ve joined a project in which the app is built using shadow-cljs. I use Cursive as my IDE. I’ve created a pom with the shadow-cljs pom command, AND I’ve copied its dependencies into a project.clj file. I thought this would make the requires in the source files resolve, but it seems not to have happened. For example in (:require [reagent.core :as r] I hover and get ‘r cannot be resolved’. Is there anything I can do to fix this?

2
cyppan09:07:08

you shouldn’t create a project.clj, shadow-cljs pom generates a maven file for you (pom.xml), so you should then import / open your repo as a maven project instead

nodename16:07:16

Thanks, I have tried that and the same problem occurs. What could my problem be?

nodename18:07:29

It doesn’t even recognize defn or let

nodename18:07:29

Refactoring is also fairly broken, do I conclude that Cursive just doesn’t work under shadow-cljs?

cyppan18:07:57

it works for me, and I did what I’ve said you :thinking_face: (+ I’ve setup a java sdk for the project as usual)

nodename19:07:36

Yes I’ve seen that, and as I said I’ve tried it. That failure is what led me to think creating a project.clj might help.

cyppan20:07:09

If it is a intellij/cursive problem, you may try to delete the .idea folder and reimport the project as a maven one. Also in intellij you have a menu “file > invalidate caches” which have resolved similar problems for me in the past (clojure syntax not recognized)

cfleming20:07:09

@U04V91K02 If you open the Maven toolwindow, do you see your pom registered there? If not, do things start working if you add it there using the + button?

greg21:07:56

I had exactly the same problem a while ago, and I gave up on shadowcljs in Cursive. I will check it again soon

nodename01:07:34

I deleted the .idea folder and reimported the pom. Things seem to be operating normally now. Thanks all!

🎉 8
Björn Ebbinghaus17:07:00

I get an unresolved symbol when calling a function defined in a protocol in another namespace. If I pull the protocol into the same ns, the symbol gets resolved.

thheller17:07:31

needs to be protocols/tick since it is defined in that ns , same as you used the protocols/Updateable

Björn Ebbinghaus17:07:00

Thanks. Makes sense.

greg21:07:00

I noticed that Cursive highlights incorrectly the code when using https://github.com/plumatic/plumbing conditional threading macros (like https://github.com/plumatic/plumbing/blob/6d713472f7324344545aa93597cb2a137b3404b3/src/plumbing/core.cljx#L308> , https://github.com/plumatic/plumbing/blob/6d713472f7324344545aa93597cb2a137b3404b3/src/plumbing/core.cljx#L301>>). Is there a way to handle it? Example:

(let [assoc-please (fn [r] (assoc r :b :B))]
  (-> {}
      (?> false (assoc :a :A))
      (?> true (assoc-please))))

imre07:07:11

you can try resolving ?> as clojure.core/-> as described at https://cursive-ide.com/userguide/macros.html#customising-symbol-resolution

greg14:07:34

Right, I forgot about this feature. Thanks. I will do it next time. Strange thing is that today I opened the IDE and these macros are no longer highlighted as yesterday. The highlighting works as I would expect (I wrote some incorrect forms to validate it). And these macros (?>, ?>>) are not added in the 'Symbol Resolution' mapping in the Preferences. How to explain that? Is the Cursive resolving macros to figure out correct highlighting?

imre16:07:04

Not sure about that. Perhaps Cursive already knows about those specific macros just failed to look them up yesterday? Only Colin could answer that I suppose