Expose theme-resolved syntax/token colors to extensions (so webviews & custom views can match the editor exactly)

[NolanLT]

The gap

Extensions can already read structural theme colors (editor background, foreground, line numbers, etc.) — in webviews these arrive as --vscode-* CSS variables, and via ThemeColor in the editor. But there is no way to get the active theme's syntax/token colors (keyword, string, comment, number, function, type…).

That means anything an extension renders outside a normal text editor — a webview, a custom view, a minimap — cannot match the editor's syntax highlighting. Today the only options are:

• ship a hardcoded palette (looks wrong on themes it wasn't tuned for), or
• bundle a whole second highlighter like Shiki and re-load the user's theme file yourself, just to re-derive colors VS Code already computed.

Both are wasteful and fragile, and neither tracks the user's real theme.

Why it matters

This blocks a whole category of extensions:

• Custom diff / review views in webviews (my use case — a side-by-side diff panel that should look exactly like the editor).
• Rich code previews / docs / inline help that embed code samples.
• Minimaps and overview renderers outside the editor.
• Anything that wants code to look like the user's code, not a guess at it.

What's already proposed

Two recent, well-scoped proposals would solve this issue:

• #319754 — Theme-resolved token-category colors on ColorTheme: ask for "the keyword color", "the string color", etc. of the active theme. Lightweight; perfect for mapping a highlighter's tokens to real theme colors.
• #319753 — Expose document tokenization with theme-resolved token colors: get per-token colors already resolved from the theme, so you can render exact highlighting with no second grammar/highlighter at all.

They build on the long-standing requests #56356 (let extensions use the syntax highlighter — same webview use case) and #32813 (programmatic access to theme colors).

Either #319754 or #319753 landing would let extensions match the editor's syntax colors natively, drop their bundled highlighters, and follow theme changes for free.

How you can help

If this would help your extension (or you've hit it as a user), please 👍 the proposals so they don't get auto-closed for lack of interest:

• 👍 API: Expose document tokenization with theme-resolved token colors vscode#319753
• 👍 API: Theme-resolved token-category colors on ColorTheme vscode#319754
• Related: #56356, #32813

A reaction on the issue's top post is what counts. Thanks!

[KainosSLS]

Ok, let me work with you.

[NolanLT]

Thanks, all you need to do is give a 👍 to the threads in my original message.

Hopefully, VSCode will get around to making the API.