Recently I began to migrate some of the code on Chlorine to REPL Tooling, so things may become more testable. I already found multiple bugs in this approach and began an integration test methodology using Electron (I say that there are three kinds of developers in the field of automated tests – the ones that don’t test, the ones that do, and test freaks. I’m probably the later).
In the beginning, the idea would be to rewrite the renderer of results and exceptions so that I could fix lots of bugs that they have. So far, it’s progressing slowly, but I already can render datomic results in a meaningful way (the last renderer was interpreting as Java objects, which they indeed are) and fix some bugs with tags and other issues.
Now, one of the things that I wanted in the new renderer is the ability to copy/paste results in a meaningful way – as I’m using UNREPL, there are lots of tags that need to be reinterpreted, like
#unrepl/browseable for datafy. These need to be “translated” to something useful for rendering on screen, with links to navigate inner details, but for copy-paste they should have a textual representation that makes sense (probably the hard part).
The results of all these experiments are quite interesting – when you evaluate something and th result is a Java object, there’s a link
... that can be used to navigate inside the object: it’ll show getters, the current class, methods that the object supports, so things like “goto definition for Java object” or “Javadocs” aren’t really necessary.
Then, one of my friends asked for a Vim option. Just for fun, I started Clematis, a port of Chlorine to NeoVim. And it seems they things are progressing faster than I thought!
Now, my first and primary editor is still Atom. This will probably not change, but the NeoVim helped me to get the “textual renderer of results” working correctly. It also helped me fix some bugs in the Atom counterpart, and showed me a direction on what to do with the tagged renderer. I also found a bug in the Clojure counterpart too, and I’ll probably need to fix it in a future version.
So, in about one week, Clematis now can connect to a REPL, evaluate blocks of code and evaluate top blocks. It also can display these results in a textual representation similar to Atom. It shares more than 80% of code with Atom (via REPL Tooling) and ClojureScript support just need to be wired. It also helped to port things to REPL Tooling in a way that I can see the Atom plug-in using the same format sooner than later. This also means that new plug-ins for other editors become incredibly easy to write (I mean – looking at Clematis source code, it’s literally two files, and combined they have about 200 lines of code, considering requires. And this considering all the hacks I had to do to reload the plug-in code when I save the editor, so…).
On Clematis, there’s still no autocomplete (I have no idea where even start), goto definitions and other things. There are some renderers that are not implemented (tag, browseable, java class), so it’s not yet fit to be the primary Clojure tool. But it’s a great proof-of-concept to see how difficult it would be to port the plug-in to another architecture.
So, what now?
Now, the only thing I regret is naming the root project “REPL Tooling” – maybe I had to search for something fancier!
Dyson Sphere Around a Pulsar – Maurício Szabo · 2022-12-08 at 02:06
[…] was to change editors, for example, to a NeoVim version that had a webview, and focus on developing Clematis. None of these were ideal, especially because the only NeoVim editor that have a programmable […]