This is in reference to the conversation that was in
https://github.com/tree-sitter/tree-sitter-scala/discussions/168 around
imports and the coloring of the final part. Taken from Eugene's comment,
which made a lot of sense to message
> In Scala we have namespace for terms and types, and they can each
> define the same name, often encouraged as "companion object", so at the
> point of import statement it's ambiguous.
This is relevant in the import case, but I also think I agree with it
most of the time when you have an uppercase identifier. While there may
be times this isn't the case, I think it's a safe default.
_The problem_
Currently when you come across string interpolation you don't get any
special highlighting for the actual interpolator meaning:
```scala
ivy"com.lihaoyi::os-lib:0.9.0"
```
I all colored the same.
_The Solution_
The pr makes 2 changes.
- The `identifier` we use for the interpolator now becomes a field for
no reason other than I thought it'd be nice to just give it a name
- A hightlight query that captures it and assigns it to `function.call`.
Problem
-------
Currently storage related modifiers use keyword.
Solution
--------
We should use `storageclass` for `private`, `protected`, and `inline`.
See also https://www.sublimetext.com/docs/scope_naming.html#storage
> Keywords that affect the storage of a variable, function or data structure should use the following scope. Examples include static, inline, const, public and private.
Problem
-------
Current grammar accepts expression immeidately after `new`,
which is not correct, and doesn't work for Scala 3 syntax.
Solution
--------
This fixes it by actually using `$.template_body`.
It does create a tricky conflict between `new A: <block>`
construct and `new A: <type>`.
To deal with that, we are using `prec.dynamic`.
susliko
Johannes Coetzee
Kasper Kondzielski
Chris Kipp
eugene yokota
ghostbuster91
Anton Sviridov