Using the REPL in Editors and IDEs

Once you stop living in the terminal alone, the REPL becomes much more than a prompt.

In a good editor integration, you can:

• evaluate the form at point
• load the current file
• inspect docs without leaving the code buffer
• switch the REPL namespace to match the file you are editing
• reload changed namespaces

That is the workflow most working Clojure developers use day to day.

For Java engineers, this is the closest analogue to having a strong IDE experience, but the center of gravity is different. The editor is not just compiling and indexing. It is actively driving a live runtime.

Learn The Common Moves Before The Tool-Specific Shortcuts

Before comparing editors, focus on the capabilities that matter everywhere.

The most valuable commands are usually:

• evaluate form before cursor
• evaluate top-level form
• load current buffer or file
• show documentation for symbol at point
• inspect a result
• refresh changed namespaces

If you learn those concepts first, switching editors later is much easier than memorizing one tool’s keybindings in isolation.

IntelliJ IDEA With Cursive

Cursive is usually the easiest landing spot for Java developers who already like IntelliJ.

The official Cursive REPL guide shows that REPLs are started through IntelliJ run configurations. Cursive can:

• start local REPLs
• run them via Leiningen or deps-based project configuration
• connect to remote nREPL or socket REPL instances

That is valuable for Java engineers because it keeps a familiar IDE frame while introducing the Clojure workflow.

Two especially useful Cursive ideas are:

• Load file in REPL: push the current file into the live runtime
• Sync files in REPL: push all out-of-date files in dependency order

Those commands make reloading much less manual than typing require calls by hand.

Cursive also supports running a REPL in debug mode, which is useful when you genuinely need JVM-style debugger help. That said, you still get the most value when the REPL remains your first-line development tool, not just an emergency console.

Visual Studio Code With Calva

Calva gives VS Code a strong Clojure workflow without asking you to adopt a heavyweight IDE.

The Calva docs describe the recommended flow as Start a Project REPL and Connect, often called Jack-in. In practice that means:

• Calva starts the right REPL shape for the project
• it connects VS Code to that REPL
• it ensures the needed nREPL and cider-nrepl pieces are available

This is a good fit if you want:

• a lighter editor than IntelliJ
• strong command-palette-driven workflows
• one environment that can handle Clojure and other stacks

The important lesson is not the exact shortcut. It is the workflow shape:

• open the project root correctly
• jack in from the editor
• evaluate forms from source buffers
• treat the live REPL connection as part of the editor, not as a separate terminal window you occasionally glance at

Emacs With CIDER

CIDER is the most keyboard-driven and REPL-centric of the three common choices here.

Its documented workflow revolves around cider-jack-in, which starts a connected REPL and injects the middleware CIDER expects. Once connected, a few commands carry a lot of daily value:

• cider-load-buffer for loading the current source buffer
• evaluation of the form at point or top-level form
• doc and JavaDoc lookup
• namespace refresh
• test execution from the editor

If you are comfortable with Emacs or willing to become comfortable with it, CIDER gives you a very direct expression of REPL-driven development. It feels less like “an IDE with a REPL plugin” and more like “an interactive Lisp environment.”

For many Java developers, that feels alien at first and then extremely efficient once the muscle memory settles in.

How To Choose As A Java Engineer

There is no universally correct answer. What matters is whether the tool makes the live evaluation loop frictionless enough that you will actually use it.

What Good Editor REPL Usage Looks Like

Regardless of tool, a strong daily workflow usually looks like this:

1. open the project from the correct root
2. start or connect the REPL from the editor
3. evaluate a namespace or file cleanly
4. evaluate smaller forms as you refine behavior
5. inspect docs and values without leaving the source buffer
6. reload or refresh when code changes span namespaces

If your workflow still consists of:

• editing code in one window
• manually copying forms into a terminal
• restarting the REPL constantly

then you have not really adopted editor REPL integration yet.

Do Not Overfocus On Keybindings

Shortcuts matter, but they are not the main lesson.

Commands change over time. Keymaps differ across operating systems. Teams customize their editors.

What survives those changes is the conceptual toolset:

• evaluate here
• load this file
• show me docs for this symbol
• refresh changed code
• inspect the live result

Once those moves are habitual, learning the specific bindings becomes a smaller task.

One Warning About Editor Magic

Editor integrations are powerful, but they can hide important facts from beginners.

For example:

• which namespace is current
• whether the editor is using nREPL or a socket REPL
• whether middleware was injected
• whether the current buffer has actually been loaded

If something feels mysterious, fall back to the mental model from the terminal chapter:

• there is a running REPL somewhere
• your editor is sending code to it
• namespace and classpath rules still apply

That prevents a lot of confusion.

Knowledge Check