Closed lunelson closed 5 years ago
The actual CSS is an implementation detail, which we keep internal. Giving users access to it is not planed. The color-customization user settings are our user 'API'. But what you suggest is that you can use variables in the color-customizations settings. That makes sense. What I'm a bit afraid of is that the next request is to allow functions as well, raising the complexity even further.
But given that extensions can manipulate settings, you could think of writing an extension that prototypes this: replicate all color settings, allow variables (and maybe functions) on it, and set the computed values programmatically to the original settings.
This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding and happy coding!
A feature which would make both
workbench.colorCustomizations
andeditor.tokenColorCustomizations
much easier to manage, would be allowing CSS custom properties as values, so definitions could be managed in one list. Electron supports them, and having them would also allow on-the-fly tweaking of global colors via the Inspector. To do this, we would also require an additional object in which those values would be set...such would then cause those values to be written to the:root
or.monaco-editor
scope of the stylesheet (I suppose).This would then allow settings like this:
I don't know much about how vscode build and applies its styles but if someone wants to give me an intro to it I'd be glad to try a PR for this.