Refactor the language-textmate module with Kotlin?

[dingyi222666]

Why refactor?

TM4E is an excellent textmate support library on java. But Android fragmentation prevents us from continuing to integrate TM4E.

As we all know, Android fragmentation is serious, so the high-version Java API supported by the new Android version is difficult to use immediately on all system versions (such as Android 14 supports Java 17, many new Java APIs are not available on Android versions lower than this). Therefore, there is “desugar”, which tries to “downgrade” the high-version Java syntax to a concrete implementation that is available on low-version Android.

TM4E uses Java 17 as its library target language and uses a lot of new Java APIs. This is cool, but in order to run on Android, we need to re-perform compatibility checks and manual testing after each manual synchronization of upstream code, and still accidentally fail to summarize all situations. Of course we can’t let it not use the new Java API. (After all, this library is not implemented by us)

This makes every synchronization of upstream code a bad experience, and bugs will appear accidentally. We are tired of desugar. Why not use Kotlin to implement a TextMate support library by ourselves, so that we don’t have to worry about desugar problems anymore?

Benefits of refactoring

First of all, we can directly get rid of meaningless desugar. It will be difficult to encounter similar problems using Kotlin.

Secondly, we can freely change the internal implementation of the TextMate support library, without having to check when manually updating the TM4E upstream code (even if we still need to manually check the update based on the VSCode implementation after implementing it ourselves).

Finally, the TM4E project will continue to develop, and related APIs may be renamed or changed at any time, which also makes us need to re-adapt these APIs when manually updating the TM4E upstream code.

Can I not refactor?

Of course you can. I just suggest refactoring, mainly because I was a bit intolerable of desugar and the extra time it took in the previous few synchronizations of upstream code. If possible, I will implement this.

How to refactor

I recommend following these steps:

1. Based on the VSCode TextMate implementation, port the TextMate support library to Kotlin.
2. Based on the VSCode languageConfiguration implementation, port its support to Kotlin.
3. Reimplement all Java code in the io.github.rosemoe.sora.langs.textmate package in Kotlin, and try to optimize some code (especially the registry package)
4. Replace the TextMate and LanguageConfiguration references under io.github.rosemoe.sora.langs.textmate. Replace it with our own support.

Epilogue

Finally, we sincerely thank TM4E for this excellent library, which allows us to add TextMate support to the editor. Of course, there is also VSCode, an excellent editor. It was it that made us think of adding TextMate support to the editor. And some of the editor’s features are also ported from it.

We also welcome anyone to comment on this issue.

---

The above text is translated from Chinese to English based on New Bing.