ROADMAP.md (4550B)
1 # CIDER Roadmap (as of July, 2020) 2 3 That's a very high-level roadmap for CIDER. It focuses on the most 4 important challenges we need to tackle. 5 6 It's meant to give users a general idea about the direction we 7 envision for the project's future, and collaborators a good list of 8 high-impact tasks to tackle. 9 10 ## Misc Features 11 12 * ~~find-references (https://github.com/clojure-emacs/cider/issues/1840)~~ (**DONE/0.22**) 13 * highlight symbol occurrences (https://github.com/clojure-emacs/cider/issues/1461) 14 * macrostep style of macro expansion (https://github.com/clojure-emacs/cider/issues/1850) 15 16 ## Internal improvements 17 18 * ~~Replace usages of Elisp's `read` with `parseedn`.~~ 19 * ~~Break down `cider-interaction.el` and remove this file completely.~~ (**DONE/0.18**) 20 * ~~Improve the connection management (https://github.com/clojure-emacs/cider/pull/2069)~~ (**DONE/0.18**) 21 * Improve nREPL callback handling (https://github.com/clojure-emacs/cider/issues/1099) 22 * ~~Better handling for huge output/results (we can warn users about it, 23 truncate it in the REPL and store the whole result internally, etc).~~ 24 25 ## Better ClojureScript support 26 27 ### Make it easier to start ClojureScript REPLs 28 29 * Implement some deps injection for ClojureScript REPLs 30 * ~~Providing meaningful errors when starting ClojureScript REPLs.~~ (**DONE/0.17**) 31 * ~~Make it possible to have a project with only a ClojureScript REPL.~~(**DONE/0.18**) 32 * ~~Merge cljs-tooling into orchard and evolve it a bit (under 33 consideration, might be better to keep it a separate library).~~ (**Done/Orchard 0.5**) 34 * Add ability to restart a ClojureScript REPL (https://github.com/clojure-emacs/cider/issues/1874) 35 36 ### Add ClojureScript support for more commands 37 38 * clojure.test 39 * tracing 40 41 ### Always show meaningful errors if a command is not supported under ClojureScript 42 43 Right now it's very confusing if you try to run a Clojure-only command with a ClojureScript REPL. 44 You'd get some really weird error instead of something nice like "command X is not supported for ClojureScript". 45 46 ### Add debugging support for ClojureScript 47 48 There's a bit of info on the subject [here](https://github.com/clojure-emacs/cider/issues/1416). 49 50 ## Implement new nREPL features 51 52 * sideloading (there's some experimental support for this) 53 * dynamic middleware loading 54 * ~~completion~~ 55 * ~~lookup~~ 56 57 ## Make CIDER somewhat Clojure-agnostic 58 59 There are many languages that provide their nREPL implementations and it'd be nice if 60 they worked with CIDER as far as the core nREPL protocol goes. 61 62 Here's [an example](https://github.com/clojure-emacs/cider/issues/2848) of how little work is needed to have CIDER work with 63 Fennel. 64 65 ## Gradual merger with refactor-nrepl 66 67 It would make sense to move some important refactor-nrepl 68 functionality into CIDER, provided it doesn't depend on anything 69 complex (e.g. building an AST for the entire project). 70 71 Below follow a few such candidates. 72 73 This merger also relies on collaboration from the refactor-nrepl team. 74 75 ### Move hotload deps to CIDER 76 77 The deps hotloading has been broken in clj-refactor.el for a while now. 78 It'd be nice if we reimplement it in CIDER. 79 80 ### Move the ns-cleanup functionality to CIDER 81 82 Pretty useful functionality, although potentially this can be achieved by shelling out some external tool as well. 83 84 ## Socket REPL support (and potentially unrepl/prepl support as well) 85 86 Eventually we want to support socket REPLs of any kind (plain, unrepl, 87 prepl) in the same manner we support nREPL today (meaning everything 88 should work with them). The bulk of the work to achieve this is 89 related to making the CIDER client and server code nREPL agnostic, 90 so. Work for this is already underway with respect to the server code 91 (that's the `orchard` project), but hasn't started on the client 92 (Emacs) side. 93 94 **Update 07/2020** Now that nREPL is once again actively maintained the priority 95 of this has dropped significantly for us. 96 97 ### Decouple the CIDER code from nREPL 98 99 * Isolate the connection-specific code in a couple of client libraries and build a 100 generic API on top of them dispatching based on the connection type. 101 102 ### Implement a socket REPL client 103 104 That should be relatively straightforward, as the communication 105 protocol for the socket REPL is pretty simple. `parseedn` should be 106 used to "encode/decode" EDN data. 107 108 ### Transition everything non-nREPL specific to Orchard 109 110 As of July, 2020 that's mostly done. We still need to decide if we want to extra pieces 111 of code like the test runner and the debugger, which are unlikely to be used outside 112 of nREPL.