|Because nREPL connections map one-to-one to REPL buffers, for the purpose of this section we use "REPL" and "connection" interchangeably.|
Life’s easy when you’re working only on a single project with a single Clojure connection. If you’re lucky enough to be one of those people then you can safely skip reading this section. Its target audience are people who have to work simultaneously on multiple projects or have multiple connections opened for the same project.
It turns out that it’s really hard to map reliably operations originating in source buffers (e.g. code evaluation) to the right connection buffer, as there are many things you have to take into account:
Is the connection mapped to some project or not?
Do you have multiple connections mapped to the same project? (e.g. a Clojure and ClojureScript REPL)
Do you have multiple connections of the same type mapped to the same project? (e.g. several Clojure REPLs)
What should happen if you try to evaluate code that’s outside of a project?
Where should you dispatch operations originating in
.cljcfiles? To the Clojure REPL? The ClojureScript REPL? To both REPLs?
CIDER started out without any support for multiple connections and through the years we’ve had several different ideas on how to support multiple connections:
Originally there was a static dispatch mechanism. You’d just manually select the active connection from a list of connections and all operations would be routed to it. This approach was simple and effective, but required you to constantly keep track of whether you’re using the right connection. This problem was further compounded by the creation of ClojureScript.
Eventually we introduced the concept of dynamic dispatch, where we’d use a combination of the filename extension and the project directory to figure out where to send operations. This approach worked reasonably well, but was problematic when you had multiple connections of the same type for the same project. There was also no logical grouping of related connections.
This brings us to the present - today’s approach to managing multiple connections is an evolution of the dynamic dispatch. Related connections are grouped together in sessions, which are tied to some context (typically a project directory). If some operation dispatch is ambiguous it will fail with an error message. You can manually link buffers, files and directories to sessions in such situations.
In the following sections we’ll go over the basic terminology with respect to connection management, and we’ll cover the typical scenarios you’d normally have to deal with. The topic might seem a bit intimidating, but it’s actually fairly straightforward once you get to know the terminology and wrap your head around the basic idea.
|In the context of this section "session" stands for a group of nREPL connections. That should not be confused with nREPL’s own notion of a session (each nREPL connection can be segregated into multiple sessions).|
CIDER maintains a grouped view of opened nREPL connections through Sesman sessions. Each session is a collection of connections which share the same nREPL server. You can, however, have multiple sessions sharing the same nREPL server (although you’re unlikely to ever need this).
Start new sessions with
C-c C-x j j
C-c C-x j s
C-c C-x j m
C-c C-x c j
C-c C-x c s
C-c C-x c m
Add new REPLs to the current session with
C-c C-x s j
C-c C-x s s
Session life-cycle management commands live on the Sesman map (C-c C-s)
C-c C-s s
C-c C-s r
C-c C-s q
sesman-start wraps around all of the aforementioned
connect commands. You can also invoke same functionality with M-x
cider or C-c M-x.
To quit or restart individual connections use cider commands
All CIDER commands (evaluation, completion, switching to REPL etc.) operate on the relevant REPL within the current session. The current session is the most relevant session among all linked session (or friendly sessions when no links exist). Session relevance is decided by the specificity of the linked contexts and recency of the REPL buffers.
If the current context is linked to a single session then that session is the current one. If multiple sessions are linked to a context (say, a project) then the current session is the one containing the most recently viewed REPL.
Links to more specific contexts have precedence. For example, if you have two sessions linked to the same project and another to a directory within that project, then the session linked to the directory is the current session. Thus, again, there is no ambiguity.
By default Sesman allows multiple simultaneous links to projects and
directories, but only one link per buffer. See
you would like to change that.
The current REPL is the most relevant REPL from the current session. REPL relevance
is determined by the type of the current buffer. For example if the current
buffer is a
clj buffer then a
clj REPL is selected. Ambiguous situations could
arise when, for instance, there are multiple
clj REPLs within a session, or
the current buffer is a
cljc buffer and both
cljs REPLs exist in
the session. In such cases the current REPL is the most recently viewed REPL of
the relevant type.
Switch to the current REPL buffer with C-c C-z. You can then use the same key combination to switch back to the Clojure(Script) buffer that you came from.
The single prefix C-u C-c C-z, will switch to the current REPL buffer and set the namespace in that buffer based on namespace in the current Clojure(Script) buffer.
Sessions can be linked to contexts (projects, directories and buffers)
C-c C-s b
C-c C-s d
C-c C-s p
C-c C-s u
|Typically you’ll want to invoke those commands in file buffers and occasionally is some special buffers (e.g. a scratch buffer). You should never run them in a REPL buffer, as a REPL is an integral part of a session.|
Sesman defines "friendly" session to allow for on-the-fly operation on
sessions from contexts where there are no explicit links. In CIDER friendly
sessions are defined by the project dependencies. For example when you use
cider-find-var (M-.) to navigate to a var definition in a
dependency project the current project’s session becomes a friendly session for
When you evaluate some code from a dependency project and there are no explicit links in that project, the most recent friendly session is used to evaluate the code. Explicitly linked sessions have precedence over the friendly sessions.
You can disable friendly session inference by customizing
Get info on all linked and friendly sessions in the current context with
C-c C-s i (
sesman-info). On C-u, display info on all
CIDER sessions. For the connection specific information use CIDER’s built-in
cider-describe-connection (C-c M-d).
An interactive view of all CIDER sessions is available through the
sesman-browser (C-c C-s w).
By default session names consist of abbreviated project name, host and port
project/dir:localhost:1234). REPL buffer name consist of the session
name and the REPL type specification post-fix
You can customize session names with
cider-session-name-template and REPL
nrepl-repl-buffer-name-template. See also
cider-format-connection-params for available formats.