Move Kotlin package

[guille]

• I'm the package's author and/or maintainer.
• I have read the docs.
• I have tagged a release with a semver version number.
• My package repo has a description and a README describing what it's for and how to use it.
• My package doesn't add context menu entries. *
• My package doesn't add key bindings. **
• Any commands are available via the command palette.
• Preferences and keybindings (if any) are listed in the menu and the command palette, and open in split view.
• If my package is a syntax it doesn't also add a color scheme. ***
• I use .gitattributes to exclude files from the package: images, test files, sublime-project/workspace.

Repo: https://github.com/guille/sublime-kotlin

My package is a Kotlin syntax. Rather than have a "Better Kotlin" package I figured this made more sense.

Two disclaimers:

• The syntax is AI generated. It does fix every open issue I saw on the old package's (and then some) but it is probably not perfect. I am not good at writing syntaxes so any maintaining will also be done with this approach, although syntax tests seem to make it output decent stuff.
• I have not tried to submit patches the old package. The last commit was 8 years ago, there have been open issues for longer, and I don't feel comfortable dumping a 1000-line syntax file on someone else.

I would understand if the change is rejected. I initially wasn't going to submit it because I don't think a lot of people use ST for Kotlin but it's been pointed out that Sublime Merge would also benefit from a better syntax.

The only "breaking" change beyond better highlighting is the scope name changes from source.Kotlin to source.kotlin. The only places I can imagine that would cause issues is in LSP-Kotlin and AFileIcon. If this is accepted I'd submit patches there too.

Comparison

Before

---

After:

[github-actions]

Package Review

Channel Diff

Removed (none), changed Kotlin, added (none).

Review for Kotlin 2026.04.24.13.41.52

1 notices:
- Consider requiring Sublime Text build >= 4171, where the API is available at import time and these initialization restrictions do not apply.

No failures

No warnings


For more details on the report messages (for example how to resolve them), go to:
https://github.com/packagecontrol/st_package_reviewer/wiki

[guille]

(Alternatively, @vkostyukov if you want to maintain it and cut a new tag in your repo please let me know)