Should we keep the @constant capture the way it is?

[ckipp01]

Currently we have a capture that looks like this:

((identifier) @constant (#lua-match? @constant "^[A-Z]"))

This will treat any identifier that starts with a uppercase letter as a constant. This will also result in things like Imports being identified as a constant like so:

import java.time.Instant
//^include
//     ^namespace
//               ^constant

This will end up being colored like this:

Do we like this? Do we want this? What's an alternative?

[cquiroz]

At first I thought, odd it would be nice to have the whole import in a single color but after thinking it a bit it is way more readable like this. However if the import does not start with a capital letter I'd like to see it with the same color, as in

import java.time

The time part should be highlighted like Instant right?

[ckipp01]

Check the reply below, I think it's a really good response to this as well.

[eed3si9n]

Traditional syntax highlighting distinguishes the definition site (e.g. def foo(x: Int)) and the use site (e.g. foo(1)), with regards to the color palette of the symbol foo.

In Strange Loop talk, Max Brunsfeld criticized it starting 6:36

For me it would help me to read the code, if all of type names were their own color, but it's not that way at all. The types are actually four different color here: char is purple, uint32_t is blue green, and the type that we are defining is black first, and yellow in another spot for some reason.

I think that section underlines the design of tree-sitter when used for syntax highlighting, and something both the grammar maintainers and editor integrators should keep in mind.

This also highlights the limitation of parser with regards to Scala. 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 will treat any identifier that starts with an uppercase letter as a constant.

Coming back to this, I think we should assume uppercased identifiers are of @type.

tree-sitter-scala/queries/highlights.scm

Lines 9 to 10 in f6bbf35

	(object_definition
	name: (identifier) @type)

That would match the @type designation currently given to both type symbol and term symbol for object.

[ckipp01]

Yea, this makes total sense. Thanks a lot of the thorough answer here! I'll update the queries with this as it makes sense to me.