That's a very high-level roadmap for CIDER. It focuses on the most important challenges we need to tackle.
It's meant to give users a general idea about the direction we envision for the project's future, and collaborators a good list of high-impact tasks to tackle.
- find-references (clojure-emacs#1840)
- basic refactoring stuff (potentially related to the merger of stuff from clj-refactor.el)
- highlight symbol occurrences (clojure-emacs#1461)
- macrostep style of macro expansion (clojure-emacs#1850)
- Replace usages of Elisp's
read
withparseedn
. Break down(DONE/0.18)cider-interaction.el
and remove this file completely.Improve the connection management (clojure-emacs#2069)(DONE/0.18)- Improve nREPL callback handling (clojure-emacs#1099)
- Better handling for huge output/results (we can warn users about it, truncate it in the REPL and store the whole result internally, etc).
- Implement some deps injection for ClojureScript REPLs
Providing meaningful errors when starting ClojureScript REPLs.(DONE/0.17)Make it possible to have a project with only a ClojureScript REPL.(DONE/0.18)- Merge cljs-tooling into orchard and evolve it a bit (under consideration, might be better to keep it a separate library).
- Add ability to restart a ClojureScript REPL (clojure-emacs#1874)
- clojure.test
- tracing
Right now it's very confusing if you try to run a Clojure-only command with a ClojureScript REPL. You'd get some really weird error instead of something nice like "command X is not supported for ClojureScript".
There's a bit of info on the subject here.
It would make sense to move some important refactor-nrepl functionality into CIDER, provided it doesn't depend on anything complex (e.g. building an AST for the entire project).
Below follow a few such candidates.
This merger also relies on collaboration from the refactor-nrepl team.
Eventually we want to support socket REPLs of any kind (plain, unrepl,
prepl) in the same manner we support nREPL today (meaning everything
should work with them). The bulk of the work to achieve this is
related to making the CIDER client and server code nREPL agnostic,
so. Work for this is already underway with respect to the server code
(that's the orchard
project), but hasn't started on the client
(Emacs) side.
- Isolate the connection-specific code in a couple of client libraries and build a generic API on top of them dispatching based on the connection type.
That should be relatively straightforward, as the communication
protocol for the socket REPL is pretty simple. parseclj
should be
used to "encode/decode" EDN data.
Already in progress, a lot of functionality already lives is orchard as of version 0.3.