x/tools/gopls: report SemanticHighlight for format string directives

[xzbdmw]

gopls version

..

go env

..

What did you do?

Currently, gopls does not report those information to client, and there exists a setting noSemanticString, while turn on, will let client highlight them.

However, some clients will benefit if gopls reports those tokens (e.g., %s), as described in golang/vscode-go#3632 (comment)

What did you see happen?

above

What did you expect to see?

above

Editor and settings

No response

Logs

No response

[gabyhelp]

Related Issues

• x/tools/gopls: semantic tokenizing of string escape/format characters #45753 (closed)
• x/tools/gopls: add syntax highlighting for go: directives #63538 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[findleyr]

We discussed this in our triage meeting today, and agree that users probably want this (this was one of the motivations for the noSemanticString setting, so that syntax highlighting can fall back to the default.

[xzbdmw]

Rust-analyzer uses a custom tokenType.FormatSpecifier instead of modifiers, I can think of two ways for gopls:

1. we can use string.placeholder (placeholder as modifier), and vscode plugin can link this modifier to some existing one by default ( I guess, not sure), some other clients will need to define their own colors.
2. use an unused (but in spec) tokenType so all clients get different colors for placeholders from literal string automatically (in case they don’t read release notes). Fron lsp spec, there is one seems reasonable:

operator: For tokens that represent an operator.

Edit: I'm going to use TokMacro for this, it is currently only used in template file.