Insuficient Capture Groups for keywords.

[EnochMtzR]

I believe the @Keyword capture groups may be lacking expressiveness.

we currently have the following capture groups for keywords:

@keyword                   ; keywords not fitting into specific categories
@keyword.coroutine         ; keywords related to coroutines (e.g. `go` in Go, `async/await` in Python)
@keyword.function          ; keywords that define a function (e.g. `func` in Go, `def` in Python)
@keyword.operator          ; operators that are English words (e.g. `and` / `or`)
@keyword.import            ; keywords for including modules (e.g. `import` / `from` in Python)
@keyword.type              ; keywords describing composite types (e.g. `struct`, `enum`)
@keyword.modifier          ; keywords modifying other constructs (e.g. `const`, `static`, `public`)
@keyword.repeat            ; keywords related to loops (e.g. `for` / `while`)
@keyword.return            ; keywords like `return` and `yield`
@keyword.debug             ; keywords related to debugging
@keyword.exception         ; keywords related to exceptions (e.g. `throw` / `catch`)

@keyword.conditional         ; keywords related to conditionals (e.g. `if` / `else`)
@keyword.conditional.ternary ; ternary operator (e.g. `?` / `:`)

@keyword.directive         ; various preprocessor directives & shebangs
@keyword.directive.define  ; preprocessor definition directives

The way they are grouped leaves certain keywords in very awkward placement and (in my opinion) lacks descriptiveness of the code's intention.

For example:

The break keyword in C-like languages is related to repeat (to break out of a loop) and conditional (to skip switch statements). This leaves this keyword in a very awkward "just a keyword" group, which leaves Theme library developers without the necessary tools to express different styles. Multiple other keywords also sit in this awkward "catchall" category, again constraining "theme" developers in how they want to express the colours of a certain language.

I believe having a capture for @keyword.control would be more expressive. This helps us express the keyword's intent. Then, we could have subgroups like @keyword.control.conditional, for example. That way, we can group all keywords that affect the control flow and differentiate them while still having a specific group for the ones that affect the flow conditionally rather than repeatably.

Also, it would be really interesting to have a @keyword.declaration capture for languages that have multiple declaration keywords like javascript where you may have let, const, or var to declare variables.

In general, I believe there is a discussion to be had to improve the way we currently categorize all keywords to prevent ending with a "catchall" group and improve expressiveness for theme library developers.

[clason]

Sorry; we are threading the needle between a) expressiveness b) manageability and c) flat hierarchy. That ship has sailed since these groups are documented and standardized upstream.