Code Navigation and Browsing

The runtime analysis only sees namespaces that have been loaded into the REPL, and each reference it reports points at the referring function’s definition rather than the exact call site. To also cover code that hasn’t been evaluated yet, CIDER can search the project’s source files on disk. It uses the lightweight info/lookup op (a single, cheap round-trip) to resolve the symbol at point to its canonical namespace and name, then scans the project’s files with a Clojure-aware text search, taking each file’s namespace aliases and :refers into account and pinpointing every occurrence.

cider-xref-fn-refs-in-source (C-c C-? s) runs this search directly and shows the results in the standard xref buffer. When no REPL is connected it falls back to matching the bare name, which is less precise but still useful.

By default, xref-find-references (M-?) uses this source search, since it reports the exact occurrences across the whole project, including code that hasn’t been loaded. The cider-xref-references-mode variable lets you fold in the runtime references too:

The two answer slightly different questions: the source search finds every occurrence (in any Clojure dialect), while the runtime search reports the calling functions (each hit points at the caller’s definition rather than the call site) and is limited to Clojure on the JVM and to loaded project namespaces. In both mode the source matches lead, and runtime hits for files the source search already scanned are dropped, so a loaded reference isn’t reported twice at two different granularities; what survives is mainly references the compiler generated from macros, which leave no textual trace.

Because the source search is textual, it’s a smart heuristic rather than a resolved index. It only looks at the project’s own source files, so it won’t find references that live in dependencies. It can include false positives such as shadowing locals or a same-named var referred from a different namespace, and it can miss references hidden in .cljc reader-conditional branches or built from strings at runtime. A faster search program helps on large projects; set xref-search-program to ripgrep if you have it installed.

Don’t forget you also have a couple of third-party alternatives:

The flat commands above answer "who uses this, right here". To explore further - "who calls the callers, and who calls them" - CIDER offers two SLIME-style browsers that present the same runtime data as an interactive tree:

Each node can be expanded with TAB to reveal the next level of the graph, so you walk it one step at a time rather than computing the whole thing up front; every level is a single round trip, taken only when you ask for it. n and p move between nodes, RET (or .) jumps to a node’s definition, and a function that calls back onto its own path is shown as a leaf so expansion can’t loop forever.

Macros are a special case: they’re expanded away at compile time, so the runtime ops never see their call sites and cider-who-calls comes up empty for them. cider-who-macroexpands (C-c C-w m) finds a macro’s use sites by searching the project’s source instead (the same mechanism as cider-xref-fn-refs-in-source).

cider-who-implements (C-c C-w i) goes the other way around: point it at a protocol and it lists the types that implement it; point it at a multimethod and it lists its methods, all on the same expandable tree. With a recent enough cider-nrepl it covers inline defrecord/deftype implementers too and jumps straight to each implementation’s source. For a multimethod, each method jumps to its defmethod - found by searching the project’s source, since the method functions themselves carry no source metadata at runtime.

Two more protocol-oriented commands round out the family. cider-type-protocols (C-c C-w t) is the reverse of cider-who-implements: point it at a type (a record or class) and it lists the protocols that type implements, including inline defrecord/deftype implementations. cider-protocols-with-method (C-c C-w p) takes a method name (by default the one at point) and lists the protocols that declare it - handy when you spot a bare method call and want to know which protocol it belongs to. Both jump to the matching protocol’s definition, and both see loaded Clojure-on-the-JVM code only. With a recent enough cider-nrepl they use a dedicated middleware op; otherwise they fall back to a client-side query that works against any nREPL.

The call-graph bindings are also available under the C-c C-? xref prefix, as C-c C-? R and C-c C-? D.