Semantic highlighting

[bentsherman]

Close #8

Semantic tokens are used on top of the syntax highlighting, so the language server need only override tokens which aren't accurately described by the TextMate grammar.

The encoding of semantic tokens is described here

The first pass just tries to provide semantic token types for named symbols like variable/function names. Some things to improve:

• support the semanticTokens/range LSP request (?)
• support semantic token deltas on individual text edits (?)
• add configuration option (is this needed on top of editor option?)
• preserve CST token ranges in AST (e.g. parameter names)

[bentsherman]

Example before/after with first pass:

Before:

After:

[bentsherman]

Second pass:

[bentsherman]

I think this is good enough for a first implementation. It mainly distinguishes variables/properties from functions, and improves highlighting for string interpolations. In the config, it better distinguishes config settings from dynamic expressions and code.

• It re-uses the textmate grammar's highlighting as much as possible in order to keep it lightweight. I also managed to get by with only a few extra bits of CST metadata for parameter name and include name/alias.

• Performance impact seems pretty minimal, so I won't worry about making it opt-in right now. But it can be disabled in the settings.json:

    "[nextflow]": {
        "editor.semanticHighlighting.enabled": false
    }

• LSP range request and deltas for text edits don't seem necessary right now. Will reconsider if performance becomes an issue.

• Embedded script highlighting and the regex highlighting issue will be addressed separately.

[ewels]

Awesome! 👏🏻 🎉