fix(themes): an imported theme keeps its colours under the semantic layer

[PathGao]

Found while drafting the reply to #676, which is why that reply has not been posted: for the reporter's setup — an imported VS Code theme — the semantic layer made things worse, not better.

What happens

A semantic token whose type the active theme does not name does not fall back to the grammar's colour. It resolves to the theme's root rule, and the root's foreground is a real colour id rather than "none":

// semanticTokensProviderStyling.js
if (tokenStyle.foreground) {                       // a ColorId; the root's is 1, always truthy
    metadata |= foregroundBits | SEMANTIC_USE_FOREGROUND;
}

// sparseTokensStore.js
bMask |= (bMetadata & SEMANTIC_USE_FOREGROUND) ? FOREGROUND_MASK : 0;
aMask = (~bMask) >>> 0;                            // the grammar's colour is masked out

getTokenStyleMetadata reports the four font styles as booleans rather than "not set", so SEMANTIC_USE_ITALIC and friends are always set too, and bold, italic, underline and strikethrough are taken over and switched off along with the colour.

Who it hit

The two built-in themes are handed semanticTokenRules() (Editor.svelte:297,313) and name every type. An imported theme is handed monacoTokenRules() alone (theme.ts), which renames TextMate scopes to the names the grammar emits. Resolving every legend entry against a theme built that way:

命中:  strong, strong.marker
落空:  heading list task quote rule fence frontmatter table code emph
       strike highlight insert link image math wikilink footnote html
       … 以及它们的 .marker

strong matches by coincidence — #676's markup.bold → strong alias happens to collide with the legend's spelling for the same construct. markup.italic aliases to emphasis and the legend says emph; one letter apart, no match.

So since the semantic layer shipped, an imported theme has been losing its heading, list, quote, table, inline-code, link and image colours to the plain default foreground, and ~~strike~~, ==highlight==, ++insert++ their font styles with them.

The fix

The alias table carries both spellings. markup.italic → emphasis and emph, markup.inline.raw → variable and code, markup.underline.link → string.link and link, plus the scopes that only the semantic layer can reach: markup.heading, entity.name.section, markup.strikethrough, markup.quote, markup.list, markup.fenced_code, meta.separator.

That is the half of #676 that could not be answered before. Monaco's tokenizer has no name for a strikethrough at all, so no rename ever reached it; the parse does, and a theme's markup.strikethrough now lands on strike.

importedThemeRules puts the app's semantic rules underneath the theme's. Monaco merges same-named rules in array order, so the theme still wins wherever it has an opinion. A construct with no markup.* scope of its own — a task checkbox, a table, a wikilink, maths — takes a deliberate colour instead of the theme's default foreground.

Test

no kind falls through to an imported theme that has nothing to say builds the theme through Monaco's own TokenTheme and asserts no kind the extractor emits resolves to the fallback rule. It asks Monaco rather than re-implementing the lookup, because re-implementing it is how you write a test that agrees with itself.

Confirmed it fails without the fix (actual: ['heading', 'list', 'task', 'quote', …]), which is the shape of the shipped bug.

The kinds are read out of semantic.rs rather than from TOKEN_TYPES, deliberately: list, task, quote and table are legend types with markers only, and asserting on the legend would demand rules for content spans that are never sent.

Verification

npm run check         809 files, 0 errors, 0 warnings
npm test              950 pass
npm run test:vitest   376 pass
cargo test            161 pass
cargo clippy          -D warnings, clean

🤖 Generated with Claude Code