Well this year has been rough for Chlorine.
Basically, I wanted to keep Chlorine plugin working, but Atom was degrading over time. So, I decided to… make a new editor from the ashes of Atom! Or, basically, reuse the plugins that already had the visual elements, for example, and creates a new thing.
That obviously didn’t go right. The reason is quite simple – in the beginning, the idea was to reuse the fragments and plugins of the Atom, even if I had to depend on internal state because, sure, Atom was stale but at least it was receiving updates and security bumps over time, even when their Electron version was really far from the latest stable.
But then Atom died and I had to make a choice. Either I would keep developing Saturn and give up Atom completely (that was one of my ideas), or I could try to keep a version of Atom that did not have the backend functionality; another option 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 webview is NyaoVim, and that is also dead.
Also, if I had to keep working on the Saturn, I will have to consider that most of the Atom plugins would not receive updates anymore, translating to “I will have to keep these items this fragments by myself”.
So, if I had to keep 80% of Atom, why not keep it 100%? In the end, I decided to keep working on Atom and finally split into a new editor called Pulsar. And this means that Chlorine keeps working, Clojure plug-ins like parinfer and paredit also keep working, as most of these are stable.
But there were some issues while I was working on the Pulsar editor – I found myself using VSCodium to use ClangD (basically a LSP server for C++) when I had to work on the native modules – and that is far from ideal. I mean, if I want to keep using Pulsar, why can’t I develop it in itself? Well, the answer is obviously because it didn’t have LSP support.
I decided to start a LSP client for the Pulsar editor. And even though Atom don’t have all the UI elements for an LSP compliant plugin, I was able to hack around with some of the community plugins so that I could make it work.
So for example, for diagnostics, it now uses the Linter UI Default and Linter packages and for some of the actions that you could do to fix things, I decided to use Intentions.
But there are some problems with this approach – first of all, probably these plugins will also be dead in a while, mainly because the author probably doesn’t want to keep them; so for the Linter package, nothing will actually change – it’s just something that receives diagnostics, and publishes to other places. Linter UI was a little bit more complicated – first, because I have a really weird configuration on my editor: I use the dark syntax theme, but a light UI theme. And most plugins can’t understand this right – for example, the linter UI package tries to use the “UI background” and the “syntax foreground” – which meant my text was gray and my UI background was white, rendering text almost unreadable.
And the other thing is that the plugin is really really ugly, and somehow dated. So I decided to take a step forward and make a linter UI – but that meant that I had to develop the Linter UI and LSP in different moments, because I want to use ClojureScript on both packages.
So I decided to do something different – I made a mono-package – and mind you, Pulsar doesn’t support mono-packages, so I had to hack around my way a little bit – for now, I have sub-directories with Pulsar packages on it and a “root directory”, which has the main entry for all packages. That way I can use only a single ClojureScript compiling pipeline to develop everything.
That may sound weird for people that are not familiar with ClojureScript, but the truth is that ClojureScript doesn’t like two different projects loaded in the same Javascript environment, both hot reloading code – one will interfere with the other. So using this “hack”, I can develop all packages at the same time, meaning that if I find a bug that affect the other package I’m developing, I can fix it right away; and as I’m using the editor while developing it, it also means that I can catch these bugs faster.
So for now, I am publishing on GitLab the ring-star mono-package. It’s basically a “mono-package” that will contain the LSP client, the Linter UI element, and some other UI elements for prompts and other things that I want to develop in the future.
And maybe even a VSCode API layer over the current Pulsar/Atom one! That last one is probably the most exciting – I want to support VSCode plugins inside Pulsar, with probably the exception of VSCode Syntax grammars and themes (these are quite internal to VSCode) and maybe add an “extended API” that could allow a plug-in made for VSCode be “more extensible” on Pulsar (that remains to be seen – so far, absolutely nothing is done on this API layer).
Finally, I’m studying a way to develop a new tree-sitter grammar support (so that we can easily upgrade to Electron 19) but that’s a topic from another time. For now, if you liked and loved Atom as I did, please know that there may be some exciting news in the future!
And if you were excited for Saturn… well… sorry. But Saturn will probably not continue, considering all things that happened this year.