Fork me on GitHub

We should probably move this to CIDER, as I don’t see much reason for this to be in cljr. It’s not really related to refactoring and I assume it’s not tied to anything complex in the other package.


I think I’d be down for all of the non-nrepl refactoring to move over. If they don’t need the middleware and are decently understandable


That has been the plan for a while now. 🙂 There’s no nREPL specific refactoring, but there are a lot of things that require an AST to work 9(e.g. rename-symbol). We’ve agreed a long time ago to move everything that doesn’t require the AST to orchard and cider-nrepl, but no one had much time to work on this. The AST-powered commands will be revisited once we figure out a better way to do the analysis. @benedek is working on some ideas in this area.


Regarding AST, there is also the tree-sitter path. It was mentioned in some other channel. Thinking about how the AST situation is for Calva, it almost hurts thinking about all the ASTs that are built and thrown away all the time. I really should look at consolidating that…


@pez It’s not like we know tree-sitter is here to stay. 😄


(and I don’t think there’s a Clojure parser based on tree-sitter yet)


I know. Just throwing it in here. 😃


There are a couple of projects like, but they don’t seem particularly mature. So, even if we go in this direction there’s some ground work that needs to be done.


The real value of tree-sitter would be if it really gets universally adopted. For our needs it’s all the same what do we use as long as it gets the job done.


I’m pretty sure MS are not planning to adopt it. They have their own tech that they fancy for this.


Could be done in user space though


Yeah, but in VS Code the built in syntax highlighter (for instance) is first class. Hopefully, whatever they decide to use, they will make the AST available to extensions.


You could use the ast for non highlighting though :)