Cursive diff has stopped working for me. Anyone else noticed this? From the repl:
(cursive/diff {:a "1" :b "2"}
{:a "1" :c "3"})
But nothing appears in IntelliJ.
I’m on version 2025.2-eap5.
Been a while since I used the diff tool, so I can’t tell you when it might have broken.Are you using the REPL inline in the editor, or from the input box in the REPL pane?
the latter
Does it work if you use the REPL from the editor, or do you have that turned off?
inline REPL is activated and does work.
Thanks, I'll check the REPL editor version tomorrow.
Thank you, Colin.
trying to connect to a socket repl on a very slow connection is failing with current 2025 cursive:
Connecting to remote Socket REPL...
Disconnected from remote server.
Exception while trying to sync input stream: java.net.SocketException: Socket closed
on previous 2022.x cursive this works fine. the process at the other end is slow - getting back a prompt can take over a minute. with 2025.x it fails quite quickly, so possibly a timeout has been introduced?I just checked this, there's no connection timeout, and that code hasn't changed in forever. What might have changed if you've upgraded IntelliJ from 2022 to 2025 is the underlying JVM (JetBrains upgraded the bundled JVM in that time), I wonder if something there has changed in the socket handling.
Do you have anything in your log which might shed more light?
I have set the project jvm to 11, but am still seeing the same issue. here are the logs
2025-08-13 08:04:56,351 [1254086] INFO - #cursive.repl.runner.RemoteReplPingService - Ping timed out, connection lost
2025-08-13 08:04:56,354 [1254089] WARN - #cursive.repl.socket-repl - Exception while trying to sync input stream: java.net.SocketException: Socket closed
perhaps it is the jvm of intellij, rather than the project, that it uses?Yes, in this case it's the JVM of IntelliJ itself which might matter, although I'm not sure how to be honest.
I'll take a look at that.
Cursive 2025.2-eap6 is out. It's a bugfix release, fixing an exception when using the kondo integration on older IntelliJ versions. https://cursive-ide.com/blog/cursive-2025.2-eap6.html
no worries. Let me know if I can help somehow
@mgardner2 This doesn't fix your issue yet, sorry, it requires a bit more thought.
scope//highlight//unused bug
Build #IU-251.27812.49, built on July 24, 2025 2025.2-eap5-251
v in v [(keyword ... is marked as unused. this is wrong. it is in use
This have been happening to me since the clj-kondo integration. It happens not only in vars but any piece of code. To fix it, you need to cut the code and paste it again, in your case, maybe removing the var name and writing it again
I can reproduce that, thanks - I'll fix it.
hey Colin, i just upgraded to IntelliJ IDEA 2025.2 and Cursive doesn’t appear to have a release compatible with it yet… i know there’s an EAP version that’s compatible with the latest IntelliJ IDEA version but i’ve been avoiding using EAP versions at work… is it possible to get a “rerelease” of the current release of Cursive that’s marked compatible with IntelliJ IDEA 2025.2 while waiting for the next Cursive release?
I will do, I have to drop my daughter at school and I'll do the release.
oh, no rush. thanks!
This is out now!
Cursive 2025.2 is out! clj-kondo support, deps completion in deps.edn and project.clj files from Clojars, Github and Maven Central along with inspections for out of date dependencies, and numerous bug fixes. https://cursive-ide.com/blog/cursive-2025.2.html
it seems the clj-kondo support shadows the recognition of the 1st use of unresolved namespace aliases in a namespace, so they are not imported automatically anymore, when i auto-complete a var in them. this was a highly convenient feature we were using all the time. it was a very welcome feature addition, when they started to work from inside rich-comments too. it helped a lot more than silly ai auto-completions... has cursive's inspections been removed in favor of clj-kondo? because even if i turn clj-kondo off, i don't get the previous behaviour back.
I'll check that, that should definitely not be affected by this.
Do I understand it correctly there is much less or any need for Clojure Extras plugin now? It was blocking the update to 2025.2 so I just turned it off and don't seem to miss anything so far.
I tested this using this repo: https://github.com/cmf/onetom-test-require. Here there's a test function in test.lib, and there's a require in src.lib which gives Cursive the example it needs for the completion. Indeed, I can't require it from src.main autocompleting using (lib/my|) (where | is the caret), but I can from src.test. I tested this using 2025.1-243 (pre-kondo) and that behaviour is consistent there. As far as I know, this should always have been the case? It's just because the production code doesn't have access to tests.
i've noticed an additional circumstance. the ns alias in question is an alias of a namespace, which resides in a test source dir. for nses in non-test source dirs, the auto-import and auto-complete still works.
In that case, I don't think it will work since your production code would normally not have access to test code, right?
correct, prod code doesn't have access to the tests, but i do have the necessary aliases enabled in the Clojure Deps tool window to make the test NSes resolvable too.
thanks for looking into this and even making an example repo. i will look into it on the weekend and add a bit more concrete example content to it to demonstrate why do we expect auto-completion. it's possible that we should organize our code differently at the end, but im not sure how.
i think the highlighting of the namespace part of symbols and keywords with a different color as the name part is still not possible with cursive alone
That's correct, but I'm going to add that too, hopefully in the next build. Then as far as I know there will be no further need for Extras.