Distinguish literal values from constant identifiers in queries

[savq]

The query capture @constant is used to highlight identifier constants, like all caps identifiers in Javascript, and also as the base highlight for literal values, like numbers and characters.

It'd be better if these two uses weren't conflated. Literals should all default to a common capture, but constant identifiers should default to the highlight of identifiers, or have one of their own. So instead of the current hierarchy:

constant
  |- builtin
      |- boolean
  |- character
  |- numeric

We'd have:

literal
  |- boolean
  |- character
  |- numeric

constant

@literal.builtin isn't needed because literals are by definition built-in. So the changes that would be needed are:

@constant.builtin -> @literal
@constant.* -> @literal.*

And manually check the remaining @constant captures to see which stay as constants and which should be considered literals. Whether there's a #match? predicate is a good litmus test to know if it's not a literal, since literals are usually handled by the grammar itself.

Other alternatives to the name @literal could be @value, @token or @atom to avoid confusion with data structure literals. But I think @literal is sufficiently clear.

I've only started to use helix recently, but if this proposal is accepted, I'd be interested in contributing the changes myself.

[the-mikedavis]

We generally follow textmate for scope names which also uses @constant: https://macromates.com/manual/en/language_grammars#naming_conventions.

Rebranding values as @literal makes sense to me but I think it's a fair (although debatable) interpretation to say that constant identifiers are closer @constants than identifiers: they're effectively the same as having a literal value in their place.

Changing to @literal also wouldn't really enable any new functionality: you can already highlight values by defining the necessary theme keys; it would just make that easier.

I don't think it's worth the breaking change it would cause to themes and queries.

[savq]

but I think it's a fair (although debatable) interpretation to say that constant identifiers are closer @Constants than identifiers: they're effectively the same as having a literal value in their place.

Sure, the idea would be to differentiate the cases where that's really true from the cases where being constant is just a convention (like in Python).

I thought Helix —being a newer editor— had a bit more flexibility here, but using the naming conventions of a more mature editor makes sense.