Cursive 1.4.0

[Colin Fleming]

Hi everyone,

1.4.0 is out now! The main new feature in this release is the creation of stub files to help symbol resolution for libraries which for one reason or another are difficult to index. Cursive works by indexing source code, and some libraries cannot easily be indexed this way for one reason or another. Datomic is the most prominent example here, for the simple reason that it’s closed source. However other libraries also do things that are difficult - Carmine and Amazonica dynamically create vars for calling APIs from an abstract description of those APIs, Conman creates vars allowing SQL queries to be executed from the queries themselves, Om creates DOM manipulation functions from a list of DOM elements and so on. And finally, libraries like Midje and Overtone simply do so much macro magic and runtime var creation that it’s unrealistic to expect to ever be able to understand their source fully.

Now, when your project uses one of these libraries, you’ll be prompted to create stubs for indexing. For Clojure code, this will load the relevant namespaces in an external process and then introspect the vars to create a source file representing the vars available for that namespace. ClojureScript code does something similar by invoking the CLJS analyser. These files are in a hidden location but will be automatically added to the indexing set for your project, and can be used for find usages, completion, doc lookup etc. Since namespaces can contain a mix of dynamically generated vars and standard vars in source, only the ones that Cursive cannot index correctly from the source will have stubs created.

Currently stubs will be created for Datomic, Midje, Om, Om Tools, Carmine, Overtone and Amazonica. In a future version, you will be able to configure the namespaces that should receive this treatment. In the case of Overtone, the stubs are required but they’re not sufficient to use Overtone comfortably - I’ll have to add further support. Currently this is designed for namespaces from libraries, so it does not work correctly with tools like Conman yet since it creates vars in your project namespaces. Also, since this change is designed for library code, Cursive will not pick up the change if you add a new require for one of these namespaces. It currently only checks when adding or removing libraries to/from the project, so the easiest way to refresh is to use the Refresh Leiningen Projects action, or the equivalent for the build tool you’re using. This will be fixed in the final release.

This release adds support for new changes in Clojure around namespaced keywords (see CLJ-1910 and CLJ-1919), which are intended to make spec easier to work with. It also fixes a related bug with :or forms in map destructuring. It also correctly renames namespaced keywords when renaming aliases.

Support has been added for IntelliJ 2016.3, and for Leiningen 2.7.0 and the new managed dependencies feature. The new clojure.* -> cljs.* namespace aliasing in ClojureScript code is now also supported.

Cursive is now smarter at defaulting the namespace type when creating new namespaces, which was something that was very annoying for users who frequently work in mixed Clojure/CLJS files. There’s also now an action to convert files between .clj, .cljs and .cljc.

Also in this release, I finally fixed the nREPL stdin issue and fixed a couple of other REPL quality of life issues, as well as numerous bugs.

Here are the issues:

Pick up remote repl port from .nrepl-port in Maven/boot projects #1473

Cursive throws an exception when entering {:12345 :abc} #1010

Put Datomic Stubs on Clojars Symbol Resolution #896

DEBUG: unknown status need-input when trying to REPL ClojureScript #358

Add support for console input #228

Cursive deadlock on IDEA startup when upgrading to the latest version #1508

Support Leiningen 2.7.0 #1506

Find usages #847

Ability to ignore certain “Require namespace” hints #1499

Keys for :or should be locally bound, not keywords or qualified symbols #1495

Add support for new namespacing in Clojure 1.9-alpha8 #1450

Support CLJS namespace aliasing #1481

Additional source path outside of project dir not included (no additional content root generated) #324

Support 2016.3 EAP #1527

Error running Leiningen tasks using trampoline in 1.4.0 EAPs #1547

unable to launch a repl for projects that don?t explicitly declare clojure version #1542

Error when using new managed deps functionality in lein 2.7.0 #1543

Stub generation process should not use debug JVM flags from project.clj #1514

Error generating stubs for module ?: Exception in thread ?main? #1524

Renaming alias does not change namespaced keywords #1511

Assoc incorrectly indented 1.4.0-eap3-2016.2 #1550

Stub generation process should filter out var overwrite warnings #1515

constant NullPointerExceptions #1216

Possible incorrect indentation for forms used in anonymous functions #1227

Occasional NPEs with 1.4.0-eap3 #1560

No closing parenthesis when starting anonymous function shorthand #1265

when reading project.clj, set OS cwd to enclosing project.clj folder (IDEA 2016.3 EAP regression) #1551

Option to deactivate editor frame on REPL command #1562

Unable to run Leiningen tasks with 1.4.0-eap3 #1561

Nil Language Error on Clojure Code Blocks in Markdown #1256

Cursive 1.4.0-eap3 can?t open REPLs in JDK 7 projects (probably because of code compiled for JDK 8) #1555

1.4.0-eap3 fails when importing multi module projects with :version #1548

Add support for converting .clj files to .cljc files #893

Detect/suggest correct Clojure filetype #904

Cheers,
Colin

[Daniel Compton]

I’m on the Cursive EAP settings. When I go to update I see the option to update to 1.4.0-eap5. Is that the same as the released version 1.4.0?

--

Daniel

[Moiz Jinia]

I faced the same problem Daniel. Turning off EAP from settings allowed me to see the new stable update. Sounds like a bug Colin?

Moiz

—

sent from phone

[Colin Fleming]

I noticed this yesterday as well - I’ll get a hold of JetBrains. It looks like a bug in their plugin update mechanism.

For those of you on the EAP releases, 1.4.0 is exactly the same as 1.4.0-eap5. I just promoted it to a stable release, principally to have a stable release supporting 2016.3 ahead of JetBrains’ GA.

[Colin Fleming]

This is due to functionality that is so unexpected, I’d consider it a bug :-). See: https://youtrack.jetbrains.com/issue/IDEA-164283#comment=27-1740242. I’ll fix this tomorrow.

[Colin Fleming]

This should be fixed now.

[Matthew Chadwick]

hi, I’m getting this error when starting a repl using lein checkouts - any ideas ? lein repl works





Bad artifact coordinates kovasb:gamma-driver:jar:, expected format is <groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>
java.lang.IllegalArgumentException: Bad artifact coordinates kovasb:gamma-driver:jar:, expected format is <groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>
at org.sonatype.aether.util.artifact.DefaultArtifact.<init>(DefaultArtifact.java:73)
at org.sonatype.aether.util.artifact.DefaultArtifact.<init>(DefaultArtifact.java:56)
at cemerick.pomegranate.aether$create_artifact.invokeStatic(aether.clj:276)
at cemerick.pomegranate.aether$create_artifact.invoke(aether.clj:273)
at clojure.core$partial$fn__4759.invoke(core.clj:2515)
at clojure.core$map$fn__4785.invoke(core.clj:2646)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.lang.LazilyPersistentVector.create(LazilyPersistentVector.java:44)
at clojure.core$vec.invokeStatic(core.clj:377)
at clojure.core$vec.invoke(core.clj:367)
at cemerick.pomegranate.aether$install_artifacts.invokeStatic(aether.clj:352)
at cemerick.pomegranate.aether$install_artifacts.doInvoke(aether.clj:336)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:646)
at clojure.core$apply.invoke(core.clj:641)
at cemerick.pomegranate.aether$install.invokeStatic(aether.clj:423)
at cemerick.pomegranate.aether$install.doInvoke(aether.clj:409)
at clojure.lang.RestFn.invoke(RestFn.java:619)
at cursive.leiningen.project$build_temporary_repo$fn__1144.invoke(project.clj:114)
at cursive.leiningen.project$build_temporary_repo.invokeStatic(project.clj:86)
at cursive.leiningen.project$build_temporary_repo.invoke(project.clj:74)
at cursive.leiningen.project$project_info.invokeStatic(project.clj:539)
at cursive.leiningen.project$project_info.invoke(project.clj:508)
at cursive.leiningen.project$invoke.invokeStatic(project.clj:580)
at cursive.leiningen.project$invoke.invoke(project.clj:575)
at clojure.lang.Var.invoke(Var.java:383)
at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke(ClojureRuntimeShimImpl.java:124)
at org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke(ClojureRuntimeShimImpl.java:117)
at cursive.leiningen.ShimBootstrap$Shim.invoke(ShimBootstrap.java:51)
at cursive.leiningen.project.LeiningenProjectDetails$getProjectDetails$1.invoke(ProjectDetails.kt:117)
at cursive.leiningen.project.LeiningenProjectDetails$getProjectDetails$1.invoke(ProjectDetails.kt:102)
at cursive.leiningen.project.LeinShimProvider.withShim(ProjectDetails.kt:50)
at cursive.leiningen.project.LeiningenProjectDetails.getProjectDetails(ProjectDetails.kt:116)
at cursive.leiningen.project.LeiningenProjectsManager$reimportAllProjects$task$1.run(LeiningenProjectsManager.kt:127)
at cursive.leiningen.LeiningenUtil$4$1.run(LeiningenUtil.java:103)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:563)
at com.intellij.openapi.progress.impl.CoreProgressManager$2.run(CoreProgressManager.java:142)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:446)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:392)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:54)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:127)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$1.run(ProgressManagerImpl.java:126)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:369)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

[Niels van Klaveren]

Can't see much without the project file, but remember with checkouts you still need the original artifact in your dependencies, it just gives priority to the checkout version in your class path resolution.