Ever since its release back in the distant universe of 2018, I was a big fan and paying user of Comma IDE. Produced by the lovely folks over at Edument, Comma was both a full-fledged, standalone IDE as well as a plugin for IntelliJ IDEA-based IDEs.
In reality the standalone version and the plugin shared the same code. The standalone Comma IDE represented a mostly rare third-party derivation of the IntelliJ IDEA Community open source platform, whereas the plugin used the more common approach of simply extending the IntelliJ IDEA applications provided by JetBrains directly.
Unfortunately as times moved on, it had reportedly become more and more difficult for Edument to align the costs of keeping up with the continuously evolving IntelliJ platform with the income generated by the Comma offerings. You can read more about that in the official announcement of Comma’s development coming to an end.
A second life for Comma
While it was obviously sad news to hear about the discontinuation of Comma as a commercial product, the community was blessed by a source release of the plugin code. In combination with the forked version of the IntelliJ Community source (intellij-ide-fork), it was once again technically possible for the community to re-create Comma in both IDE and plugin form.
I kept that very possibility in the back of my mind as the days, weeks, and months ticked over after the discontinuation announcement in February. I have learned to tolerate Java as a result of my $day-job, but I was also willing to wait and see if some other willing soul would appear and revive Comma (in the words of management’s clueless response to revelations of efforts that required overtime, “work smarter, not harder”).
By August, however, I had the tuits to take the efforts up myself and so dove into trying to re-create the standalone Comma IDE.
The pace of change is certainly a thing
I quickly collided into a hard truth about the era of IntelliJ Community that Comma IDE was built against. The comma-223.4884 branch of intellij-ide-fork is 79,982 commits behind the code in the intellij-comunity repository. Those ~80k commits represent only about 24 months of activity. That’s a lot of change!
One of the most crucial changes that was being undertaken over those months, and actually over several years preceding them, was the transition from a build system called JPS to the Gradle IntelliJ Plugin. From what I understand, JPS requires a local checkout fo intellij-community (or a custom fork such as we find in intellij-ide-fork) — something that the Gradle IntelliJ Plugin does not.
Unfortunately, there is no current way to use Gradle IntelliJ Plugin to build a standalone IDE. (The documentation implies that this is an eventual goal, but I’ve heard that this page has been in place for years without update).
I spent two weeks trying and failing to make any sensible progress with JPS and a checkout of intellij-ide-fork rebased onto the latest intellij-community before finally setting aside the dream of a standalone Comma (for now…).
Catching up
After switching over to the Gradle Intellij Plugin, progress went from non-existent to quite fast-paced. Switching from targeting standalone to developing a plugin was clearly the right choice for the moment.
There was another course correction which completely transformed the velocity of change…
IntelliJ provides an option in the Code menu: Convert Java File to Kotlin File. They should put up a warning that any current tolerance levels for writing Java code will almost certainly decrease precipitously. I know mine did! There’s just zero reason — in this or any universe — to start a new codebase in Java when you can write Kotlin and integrate with Java libraries seamlessly.
At some point I’m going to try the same trick with the Java implementation of NQP.
A somewhat complete list of changes
- All references of Perl 6 replaced with Raku.
- 49 Annotations were rewritten as Inspections, along with 34 associated Fixes.
- Inspections can be selectively enabled/disabled from the IntelliJ settings.
- New Raku project setup that uses the latest Kotlin UI DSL instead of deprecated internals.
- Complete rewrite of
META6.jsonhandling based on Kotlin serialization. - Introduced a service that checks if the project contains the core
Rakudosource.- If so, it prompts the user whether they want to disable a handful of inspections that can get thrown off by core source code (such as attributes introduced in the bootstrap but used in the class source).
- Major cleanup and revision of services in general.
- Complete rewrite of fetching the ecosystem.
- Complete rewrite of package management.
- Migration of storing the Raku SDK to today’s recommended approach.
- Added NQP syntax highlighting.
- Added ‘🦋’ menu for quickly setting the Raku SDK version and launching REPLs.
A few of the things yet to be addressed
- Comma had quite a comprehensive test suite. Reanimate it!
- Validate that all Cro-specific functionality is working as expected.
- Look into some highlighting related parser issues.
- Fix dependency management for names that use
:auth,:ver, etc. - Add a UI for installing modules.
- Migrate as many Java files to Kotlin as possible (some that need
staticcan’t be reasonably converted yet) - Publish to the Jetbrains Marketplace.
- Migrate the repo to the
github.com/Rakucommunity namespace. - Include some additional themes, if possible.
What’s in a name?
We’ve been calling the revitalized plugin comma-plugin 2.0. However, in consultation with Jonathan Worthington and with current users, the plan is to rename the plugin to simply Raku before publishing to the Jetbrains Marketplace.
This aligns with the naming scheme of most other programming language plugins for IntelliJ. It does have the disadvantage of being harder to reference in communication. Therefore I somewhat expect to keep using Comma or perhaps The Plugin to refer to the efforts in IRC and elsewhere.
Concluding thoughts
IntelliJ IDEA is a fast-moving target and coding a plugin for it has enlightened me to some of the dynamics that probably contributed to the cancellation of Comma as a commercial product.
That said, the IntelliJ IDEA Platform is quite a pleasure to code against. It is generally well-documented and has clearly benefited from two decades of evolution. That always carries some baggage but for the most part I felt like I was working with a really well-designed ecosystem of IDE subsystems.
Kotlin is an incredible leap forward for working with legacy Java code and the JVM. I was feeling like my Java code was hitting a decent stride in terms of concision and expressiveness.
After my fateful decision to use IntelliJ’s automatic Java-to-Kotlin converter, that feeling has significantly evaporated. Writing Java is back to feeling hopelessly verbose, even in its sharpest forms. (Forget about JDK < 17! Instead, write Kotlin and target those ancient versions instead.)
So, approach Kotlin with caution if you’re going to be forced to write Java at work. It’s still worth it, in my opinion. I’ll have to write some posts about what I like about it some other time.
Interested in giving the Raku plugin for IntelliJ a try? Please check out the source or download the latest release.
3 thoughts on “Day 20 – Re-introducing a Raku plugin for IntelliJ IDEA”