Cursive bundles the REPL, the test runner and the debugger into one Clojure IDE

The repository is a tracker and a wiki, not the source code

The first thing to understand about Cursive is what this repository is not. It is not the IDE. The readme says the repository mostly exists to provide an issue tracker and a wiki, and that full details are available on the project's own site at cursive-ide.com.

That claim matches the file listing. The repository contains exactly three files at the top level, CHANGELOG.md, README.md and VERSIONS.md. There is no source tree, no build configuration and no dependency manifest.

So the open source question has a simple answer. The product is distributed by its vendor, and the repository is the public record of it: the changelog for what changed, the versions file for what exists, the issue tracker for what is broken and the wiki for how to work around it. No licence is stated for the repository.

That makes Cursive a different kind of dependency from the usual open source review. You are not picking a codebase to fork, you are picking a tool to run, and the things worth checking are the release history, the response to new Clojure versions and the price of the licence, none of which live in a package manifest.

Real-time error highlighting is the editor's main argument

The Intelligent Editor is listed first, and the three things under it are code completion, syntax highlighting and real-time error highlighting.

The third of those is the one that changes how you work in a Lisp, and it is worth spelling out why. In a language where parentheses carry structure and a form is only well formed when it closes, the feedback loop is different from a curly brace language. The editor is not just colouring text, it is reporting errors in the code as you type, which for a Lisp means the structural problems surface at the point of writing rather than at compile time.

Code completion and syntax highlighting are listed without detail, so there is nothing more to say about them beyond what the readme claims. The editor also lists smart, customisable formatting support, which for Clojure means the formatting is not a fixed style but something you configure.

The interesting thing is that these features are listed as the baseline rather than the differentiator. The items further down the list, the REPL, the test runner, the debugger and the structural editing, are where the substance of a Clojure IDE lies, and where the review that follows spends its time.

ClojureScript is treated as a first-class target

The readme claims first-class ClojureScript support, and states that nearly all functionality is equivalent in Clojure and ClojureScript.

That claim is doing real work in the list, because several other entries depend on it. REPL integration covers clojure.main style REPLs for Clojure and ClojureScript. Test integration runs clojure.test tests. The debugger supports debugging Clojure. If a feature set applied only to the JVM language, the ClojureScript story would be a reduced one, and the readme is asserting that it is not.

The phrase nearly all is the honest qualifier. Nothing in the repository says which features are excluded, so a team that depends on a specific capability, say the debugger in a ClojureScript build, would have to confirm that with the vendor rather than read it off a list.

For the ecosystem in general, treating the two languages as equivalent in one tool matters more than it might seem. A project that compiles to both, a library that ships a Clojure core and a ClojureScript implementation, and a team that moves between them, all benefit from an IDE that does not treat one as a secondary target.

REPL integration covers nREPL and clojure.main

REPL integration is described as full integration with nREPL and with clojure.main style REPLs, for both Clojure and ClojureScript.

The distinction between the two matters in practice. nREPL is a networked REPL server that the editor connects to, which is what makes running against a live process, a REPL inside a running application or a remote JVM possible. A clojure.main style REPL is the plain process that the language ships with, which is what you get when you start a project without any tooling around it. A Clojure IDE that only spoke nREPL would force a dependency on a server even for the simplest project, and one that only spoke clojure.main would not be able to attach to anything.

The debugger entry adds the second kind of REPL to the picture. Full support for debugging Clojure is listed, including expression evaluation and debug REPLs. A debug REPL is a REPL that runs inside the paused execution, which is the feature that makes a debugger usable in a language where the interesting state is a suspended evaluation rather than a stack of frames.

Together with the Code Navigation entry, which covers project and structure views, navigation to symbols, namespaces and classes, and Find Usages, this is the part of the product that determines whether you can work in the IDE all day rather than only editing files in it.

Tests run inside the editor and failures arrive as visual diffs

Test integration is listed as interactive running of clojure.test tests, with failures marked in the editor and visual diffs.

Running clojure.test is not difficult, and any shell based workflow can do it. What the IDE adds is the loop. Failures marked in the editor means the failing form is highlighted where you wrote it, rather than in a console you have to read and then map back to a file. Visual diffs mean that when a test compares two values, the difference is shown as a diff instead of two printed representations you compare by eye.

For Clojure specifically, the reason this is not a trivial feature is the data. Clojure code produces data structures as a matter of course, and test expectations are frequently maps, vectors and sets whose printed form can be long and where the order of printed keys is not the order you care about. A proper diff of the expected and actual values removes a whole category of debugging friction.

The readme's wording is that this is interactive running, so the tests are started and inspected from the IDE rather than from a terminal. The editor and the test runner are two parts of the same tool, which is the pattern the rest of the feature list follows.

Paredit, refactorings and Java interop with type inference

Structural Editing is listed as full support for paredit style editing. Paredit is the discipline of editing Lisp code without unbalanced parentheses, where the editor inserts and removes closing delimiters to keep the form valid. For a language where a missing paren is the most common error, this removes an entire class of mistake.

The Refactorings entry lists rename, extract let, automatic imports and requires, and more. Automatic imports and requires are the Clojure specific part, since the namespace declaration at the top of a file is a separate act from the code that uses a function. A refactoring that adds the require for you keeps the two in step.

Interop Support is described as best in class support for Java interop, including smart completion using type inference. This is the largest differentiator from a general purpose editor with a Clojure mode. Clojure calls Java methods dynamically, so the editor has to resolve types to know what a form returns, and once it does that it can complete method names and arguments correctly rather than offering every method that exists on Object.

Taken together, the editor entries, the navigation entries, the REPL and the debugger amount to a single claim: the IDE is meant to be where you work on Clojure, not merely where you type it.

Leiningen support is where multi-module projects are handled

Leiningen support is listed as full support for Leiningen, including support for large multi-module projects. That clause is the substance of the entry.

A single module Leiningen project is easy for any tool that understands project.clj. A multi-module setup has a root project, subprojects with their own project.clj files, and dependencies between them, and a tool that does not model that structure will show you a project tree that does not match reality, misattribute dependencies, or fail to find the source of a symbol used across modules.

The other side of this is the dependency file itself. Clojure's tooling story has moved towards tools.deps and Clojure CLI over the years, and the readme names Leiningen specifically rather than describing build tool support in general. For a team on Leiningen that is the entry point they need. For a team on the Clojure CLI, the readme is silent, and that silence is a question to put to the vendor before adopting.

On maintenance, the repository is not archived and the last push was on 2026-10-20, with no GitHub releases. The public record of versions lives in VERSIONS.md and the history in CHANGELOG.md, which are the two files to read when you are deciding whether the current release supports the Clojure version your project is on.

Editorial conclusion

Cursive fits teams that write Clojure or ClojureScript daily and want the REPL, the test runner, paredit and the debugger in one application rather than assembled from separate tools. It does not fit anyone who needs open source, a self hosted build or a vendored copy, since the repository holds only a README, a changelog and a versions file, no licence is stated and the product is distributed by its vendor. Before you adopt it, check the VERSIONS.md file for the release that supports your Clojure version, confirm your build tool works with the Leiningen support described, and read the CHANGELOG.md file to see how quickly the project responds to the Clojure releases you depend on.

Frequently asked questions

Official sources

1. cursive-ide/cursive on GitHub
2. Issues
3. README