Extended theme customisation syntax

[ghost]

Closes #103694.

• Multiple [scope] per customisation
• Wildcard scopes using *

Similar themes in large packs might need to be customised the same way.
Can lead to verbose code as explained in #103694 (already existent):

{
    "workbench.colorCustomizations": {
        "[Material Theme Palenight]": {
            "activityBarBadge.background": "#c792ea",
            "activityBar.activeBorder": "#c792ea",
            "breadcrumb.activeSelectionForeground": "#c792ea",
            "statusBarItem.remoteBackground": "#c792ea"
        },
        "[Material Theme Palenight High Contrast]": {
            "activityBarBadge.background": "#c792ea",
            "activityBar.activeBorder": "#c792ea",
            "breadcrumb.activeSelectionForeground": "#c792ea",
            "statusBarItem.remoteBackground": "#c792ea"
        },
        "[Community Material Theme Palenight]": {
            "activityBarBadge.background": "#c792ea",
            "activityBar.activeBorder": "#c792ea",
            "breadcrumb.activeSelectionForeground": "#c792ea",
            "statusBarItem.remoteBackground": "#c792ea"
        },
        "[Community Material Theme Palenight High Contrast]": {
            "activityBarBadge.background": "#c792ea",
            "activityBar.activeBorder": "#c792ea",
            "breadcrumb.activeSelectionForeground": "#c792ea",
            "statusBarItem.remoteBackground": "#c792ea"
        }
    }
}

This pull adds a new syntax that shortens all of that to 1 wildcard scope:

{
    "workbench.colorCustomizations": {
        "[*Material Theme Palenight*]": {
            "activityBarBadge.background": "#c792ea",
            "activityBar.activeBorder": "#c792ea",
            "breadcrumb.activeSelectionForeground": "#c792ea",
            "statusBarItem.remoteBackground": "#c792ea"
        }
    }
}

The * wildcards matches zero or more of any character.
Multiple scopes are legal, delimited by the regex /\]\s*\[/. This will enhance settings.json keys:

• workbench.colorCustomizations
• editor.colorCustomizations editor.tokenColorCustomizations editor.semanticTokenColorCustomizations

@aeschli

[ghost]

All CLA requirements met.

[ghost]

Used String.startsWith to pass code hygiene test.

[aeschli]

Can you describe in the description what problem you want to solve and how what syntax you propose?

[ghost]

Done.

[ghost]

Do I change the configuration schema?

vscode/src/vs/workbench/services/themes/common/themeConfiguration.ts

Lines 199 to 206 in 412ee9a

	for (let t of themes) {
	// add theme specific color customization ("[Abyss]":{ ... })
	const themeId = `[${t.settingsId}]`;
	themeSpecificWorkbenchColors.properties![themeId] = workbenchColors;
	themeSpecificTokenColors.properties![themeId] = tokenColors;
	themeSpecificSemanticTokenColors.properties![themeId] = semanticTokenColorSchema;
	experimentalThemeSpecificSemanticTokenColors.properties![themeId] = { $ref: tokenStylingSchemaId, additionalProperties: false };
	}

Late addition - how do I add tests?

[ghost]

A) Test rerun please B) few questions above.

[aeschli]

We currently have no tests covering how the settings are read out. If you want to add unit tests for your code, that would be welcome. They would go to src/vs/workbench/services/themes/test/electron-browser

Not sure what you mean by Do I change the configuration schema?.
To get code completion in the settings JSON editor, we should adapt the configuration schema.
I think it can be done with the 'patternProperties' property: https://json-schema.org/understanding-json-schema/reference/object.html#pattern-properties

[ghost]

I've read the JSON schema doc. But I'm still unsure on how I implement the code completion on multiple scopes e.g. [Monokai] [Monokai Dimmed]?

[aeschli]

The schema based completions are too limited, but validation will work. Better completions could be added programmatically, but I don't think we should go there. You can add some defaultSnippets as seen here:
https://github.com/microsoft/vscode/blob/main/extensions/configuration-editing/schemas/attachContainer.schema.json#L24

[ghost]

Hmm. Alright. Should I remove autocompletion of [...] scopes altogether? I suspect it's a a rather inconsistent UX to provide autocompletion for the first scope only (might get a lot of bug reports too)

[aeschli]

The completions for single theme customizations (what we currently support) can stay in, no?

[ghost]

Alright, I'll look into the patternProperties validation

[ghost]

I don't understand how to write tests, nor what naming convention to use.
Leave it to an engineer when test coverage becomes a concern?

[aeschli]

@4086606 That's ok. Let me know when the PR is ready to be reviewed

[ghost]

Should be okay for review. I don't like the as usage in getThemeSpecificColors. Maybe workbenchThemeService module could specify theme scopes as a separate optional property? Not sure how to change that and make isThemeScope a type assert

[ghost]

Using this pattern, I can create scoped property types:

export type ThemeScopeKey = `[${string}$]`;

So we need template literal types in eslint which means @typescript-eslint/parser^4.7.0 😔

[ghost]

Tongue twister of a name 🙈 any suggestions or is verbose better

[ghost]

After second thought, the changes to workbenchThemeService module are fine. The as usage is unpleasant but seems to work at compile time and that's fine by me (instead of waiting for TS to get new features). I think this pull is ready for merging.

[ghost]

@aeschli now that #103694 has the required number of 👍🏾, could this pull be added to the v1.59.0 release?

[aeschli]

Thanks a lot, @4086606 , and sorry for the wait!