# Kotlin syntax for Sublime Text

This package contains a Sublime Text syntax for the [Kotlin](https://kotlinlang.org/) language. It is only available for versions of ST equal or newer to 4075.

Its main aim is replacing an [older package](https://github.com/vkostyukov/kotlin-sublime-package) that had lackluster support for newer features and broke highlighting in many edge cases.

>[!NOTE]
> The other package sets a `source.Kotlin` scope. This one follows a more standard `source.kotlin`

## Rollback

If you want to use the previous package, you will need to disable the package and install the previous package manually, following the [instructions on their README](https://github.com/vkostyukov/kotlin-sublime-package#installation). I would encourage you to open an issue on this repo so we can improve the package, though!

## Installation

Most users will want to install via Package Control, where the package is named "Kotlin".

## Contributing

This syntax was generated by AI. Because currently-available AI is terrible at dealing with sublime syntax format, I used [this custom harness](https://github.com/guille/sublime-syntax-test-yaml) to write tests. That means syntax tests are duplicated across two places:

- yaml_tests: These are AI inputs. The harness translates them to sublime syntax test files.
- tests: These are sublime syntax test files, added manually or via conversion from the YAML tests.

A file like `yaml_tests/foo.yaml` generates a corresponding `tests/syntax_test_foo`.

**Experienced syntax writers** are welcome to contribute as they usually would, ensuring their changes include new tests. It is fine to only write sublime syntax tests, just make sure there is no clashing in the names. If you want to make an edit to the existing syntax tests, you will need to adjust the corresponding YAML test and re-generate them. Sorry!

**AI contributions** are accepted, with some caveats:
- It is _very strongly recommended_ you follow the instructions [here](https://github.com/guille/sublime-syntax-test-yaml) to set up your environment for developing. The documentation on that repo is admittedly not great but I think it's simple enough that it shouldn't be an issue.
- PRs must have sufficient testing coverage for new changes and passing regression tests. Old tests must be passing and may only be adjusted when they were incorrect or incomplete. Removing other test cases would indicate you've introduced a regression.
- Please use capable models. The first version of the syntax was generated with GPT-5.4 on xhigh. Smaller models are likely to struggle more and introduce bugs.