[themes] Themes don't support background styling
Tyriar opened this issue · 154 comments
.tmTheme files allow specification of background colors which don't seem to be supported, for example:
<dict>
<key>name</key>
<string>Separator</string>
<key>scope</key>
<string>meta.separator</string>
<key>settings</key>
<dict>
<key>background</key>
<string>#E0E0E0</string>
<key>foreground</key>
<string>#373B41</string>
</dict>
</dict>This is especially problematic for themes that attempt to invert background and use a similar foreground to the text view's background color (#2158)
We had it in, but turned it off as it conflicted badly with the other background decorations we have (selection, word highlighting).
I'd say we accept this as limitation and tell to better use themes that don't rely on background colors.
It's such a handy feature of tmThemes though to draw attention to important things. it's used frequently across themes for invalid and deprecated scopes.
I'd say we accept this as limitation and tell to better use themes that don't rely on background colors.
I strongly disagree with this. Rather than disabling a core component of tmThemes, you would be better off encouraging people to properly port their favorite tmThemes to support VSC's custom background keys when the backgrounds conflict.
Consider the difference in message:
Current: "if you rely on a theme that uses different background colors for different scopes, you must switch themes completely because we have disabled this functionality."
Port on conflict: "if you rely on a theme that uses background colors, you may need to make a minor update to the theme in order for it to look great in VSC (or you could switch to a different theme if that's too much effort)."
The first gives the user no options, and does nothing to encourage support for VSC's unique theme settings beyond themes specifically authored for VSC.
The second allows the user to make use of whatever theme they like (with caveats), and encourages theme developers to add support for VSC's custom theme keys to existing themes because it broadens the number of editors the theme will support without impacting the theme's display in other editors.
It's bizarre to me that you want to take pains to support tmThemes out of the box (to the point of breaking your to-my-mind more sensical scope targeting logic in 1.9), but then silently disable a core colorization component because it sometimes conflicts with your proprietary additions.
You should add some documentation about which keys you support in a .tmTheme. https://code.visualstudio.com/docs/getstarted/theme-color-reference Would be a good place.
Does this apply to blocked comments too? I'm having a difficult time trying to figure out how to change the background color of a multi-line comment.
Example:
<dict>
<key>name</key>
<string>Block comment</string>
<key>scope</key>
<string>source comment.block</string>
<key>settings</key>
<dict>
<key>background</key>
<string>#9b9b9b</string>
<key>foreground</key>
<string>#FFFFFF</string>
</dict>
</dict>
The background color code is not getting applied here. Only the foreground (text) color.
I'd like to be able to style the background so + 1 from me.
+1 for me as well. I wanted to port my favorite emacs theme to Code and now I don't see the point. Will this be re-implemented?
Maybe the conflict can be resolved by adding an alpha value to the color so that the colors can bleed through each other. This is a very desirable and goes a long way to improving readability. One such use case is embedded languages with their own syntax highlighting. Without a background color, it can become difficult quickly distinguish that the embedded language as a different block of logic without making the entire block monochromatic.
I think this is what I've been searching for since I moved from sublime. On sublime I had a theme that, on the same php file, had different color backgrounds for PHP, HTML and JS code. Is this the situation here?
On sublime I had a theme that, on the same php file, had different color backgrounds for PHP, HTML and JS code. Is this the situation here?
The situation here is that it is impossible for themes to have different background colors for different scopes. So you cannot duplicate your Sublime theme in VSCode.
Sadly this was working a while ago
@immigrantsheep I don't believe the editor ever had support for background colors.
My mistake, I was fresh on the team at that point 😄
Since it was turned off, is it possible for it to be turned back on by users who need it?
To get the background colors to work correctly requires additional work. We currently have no resources to look at that.
Would really like this wasn't until I'd built my textMateRules using editor.tokenColorCustomizations that I spotted the background wasn't being set but the foreground was, which inevitably sent me here looking for a fix.
+1 for me used several hours to find out why my theme wasn't showing background Color on Scope Settings. (and several more to realize it was not my fault -.-)
+1
I have a large MD document in which i'm having trouble spotting the fenced codes from the normal text
This is the only reason I haven't switched to using VSCode. I use a custom build theme and have for many years. I have spent years perfecting my custom theme to my liking, so changing it is not welcomed, especially when almost all other code editors allow it. Also rebuilding my custom theme is not something I want to do either, as it would still change many things that do use a background color.
Not having the ability to style the theme how users want it restricts people from doing what they want to do and is forcing them to change. Why make people change what they have been doing for years, because it conflicts with something VSCode built and didn't think about?
We had it in, but turned it off as it conflicted badly with the other background decorations we have (selection, word highlighting).
I'd say we accept this as limitation and tell to better use themes that don't rely on background colors.
This is really not a good explanation and a poor excuse. Perhaps you should consider that people do use background colors. If it conflicts with background decorations, than that's on the user to either change those colors, or let them decide if they want to live with it or not, not for the editor to say "do what I want you to do, no exceptions." This is almost as typical as Microsoft IE giving excuses over the years for always being very far behind other browsers. Ignoring the people who use it, while just doing whatever they want, and in turn losing a large amount of the market.
Telling people to use a different theme is like telling a client "just use different colors", and is not the kind of answer you want to here as a user. That's like saying "Sorry we don't care, just change how you do things because we do not want to take the time to support how people have been doing things for years".
Just my two cents.
I would also REALLY love to see this put back in; it's very helpful for templating language (PHP, Razor, etc) to distinguish which part is the templating language and which part is the raw output. I haven't used VS for a while, but IIRC, Visual Studio does the same for Razor directives - so why not Visual Studio Code?
I understand there being conflicts with other highlighting features, but wouldn't that be a matter of simply adding in new scopes, allowing them to be controlled by the theme itself? What's wrong with allowing user themes to style the background of wherever VS Code currently highlights text?
There can be a theme that offers a bad use of background colors but one can make an extension to replace all the source codes with nonesense on formatting, show unrelated funny cat ascii art on hover and replace intellisense suggestions with the list of US box office movies.
Any feature of the vscode API can be used in a bad way therefore if you go on with that logic you must disable the whole API and extensibility of the vscode.
It’s the users job to reason if they want the intellisense to show them box office movies and it’s also the users job to see if they want a theme that offers wrong coloring.
Meanwhile, there are a ton of very nice themes like Neon Glow and Tutti Fruity where the background colors are all the beautiful parts and without background coloes they don’t look even 10% as good.
This thing it's the only customization I need to use VS Code as my programming editor
If the problem, as @aeschli says, it's related to the colors of selection, word highlighting, ... the solution it's very easy, add these options (selection, word hightlighting, ...) to the themes and the theme creators will have the option to change all, adjusting they to the color scheme they used on the theme.
VS Code it's nearly fully customizable so why do not add more power...
@NetVicious Yes, this! Maybe a middle ground could be that if the author of said library has not designated the required colors or perhaps turn on a flag explicitly mentioning that they have, a quiet error is logged and the background color behaves as it currently does.
A third option could be a flag in the VS Code settings page to enable background change for tmThemes files with a big warning about this can create problems. Another solution could be a floating button after a theme change allowing the user to undo the theme change, like Windows does when you're changing the screen resolution. If the user sees the theme it's not working good with the colors he can undo the theme change.
PD: Someone knows which was the last version of VS Code which allowed to change background color.
This is where I use the background in my theme:
{
"tokenColors": [
{
"name": "Embedded",
"scope": "markup.fenced_code.block.markdown",
"settings": {
"background": "#00000022"
}
}
]
}And this is what it looks like (VS Code vs Sublime Text):
I'd love to be able to get that darker background in VS code. Can that be achieved in some other way other than background?
I hear you, but it's another complexity on top of what we have. My estimate is that it's 1-2 milestone work to get it fully right. So vote for it so this makes it to a plan.
I just noticed that backgrounds on backgrounds is already implemented on the diff view and it works just as expected and very good:
Given the fact that this conversation has been going on for such a long time and almost everyone gave really good facts on how right it is, how possible it is, how much it is need and so and and so forth... Isn't it better to come to a conclusion? It feels as it's taking too long... (thinking for 2 years on token backgrounds is a little bit too much)
@NetVicious In my comment I just estimated the work, no commitment to work on the issue. As 1-2 month is a considerable investment, this needs to be justified by the number of votes.
Depends all on the number of votes for other requests. When creating the roadmap for the coming months (see https://github.com/Microsoft/vscode/wiki/Roadmap) we look at the top voted issues and try to find solutions for them. Some features have over 2000 votes...
I've just tweeted out to my followers, hopefully, it will raise awareness...
Recommend others do the same.
+1 for me this is also the only reason not to switch from sublime text. I would love to have this feature be impelemented.
+1
Would love to see this. I'm stuck on Atom because I can't live without https://atom.io/themes/flatwhite-syntax.
I hope that the background color will be supported, because it is very useful.
For example, if you're working with Wordpress themes - unfortunately Wordpress mixes HTML and PHP, so a different background for PHP in WP templates helps a lot
3 years and still going... :(
+1 Love my sublime theme with different background colors for PHP, JS and HTML. Would like to switch to vscode if this feature is supported!
@wangweixuan can you confirm with the commit you send some days ago will fix this bug and will allow us to have themes with background-color ?
With only that change this bug will be fixed?
I know @aeschli said the background color selection on the themes can create problems if the developer of the theme uses the same colors VSCode uses for selection or word highlighting. But let developers to solve that problem instead of limiting us.
Just passing by, tackled this issue trying to add background color for all type tokens in .js files.
I'm using Latest TypeScript and Javascript Grammar to support more expressive rules for types syntax highlighting in js files.
The feature for background color in .tmtheme files still doesn't work.
VSCode insiders version 1.33
That's why i'm using WebStorm, there background of mixing code HTML/Js working perfectly. If VsCode make this update, i change to them...
Espresso is a really good looking editor. It has very good looking icons and vibrant sidebar are big factors, but the most screen real-estate belongs to the theme which uses significant amounts of background colors to make it cute and pretty.
+1
This would make life so much easier. Upvote! +1
Depends all on the number of votes for other requests. When creating the roadmap for the coming months (see https://github.com/Microsoft/vscode/wiki/Roadmap) we look at the top voted issues and try to find solutions for them. Some features have over 2000 votes...
How many "votes" did adding font changing need? Or obscure stuff like changing the color of the cursor?? This is basic functionality. Most people wont "vote" for this sort of thing becuse they assume something so obvious is already included. What a silly argument not to add it. Reminds me of the Chrome team refusing to add bookmark dividers. I think something went wrong and im in the bizarre-o timeline.
I just switched from Sublime Text 3 to VSCode. I am able to fix sluggishness in VSCode by getting fast PCs. However, I can't fix missing token background colors.
+1
+1
If you want to vote, simply add 👍 in the first post. In this way, they set priorities for future functions
It's better than creating another +1 post
By the way, "VSCode Dev Team" I'm begging you to implement it. It's REALLY useful! We all wait for it
Please add [background] styling
Is there at least a work around for accomplishing this?
Is there at least a work around for accomplishing this?
No. There it's no workaround to get that at this moment.
That's the main objective of this feature-request.
@NetVicious there is a work around I found - you can just use text decorations.
Not exactly ideal, but it works well enough.
@NetVicious there is a work around I found - you can just use text decorations.
Not exactly ideal, but it works well enough.
That looks pretty neat actually. Do you mind sharing how you did that?
That looks pretty neat actually. Do you mind sharing how you did that?
@daniglas
I am also very curious!
Sure thing:
Basically this is 1 language with 2 embedded languages. Sql is blue and Groovy is red.
I wrote a set of regular expressions to return sql and groovy vscode.Range(s) based on the brackets you can see in the picture(Sql [], Groovy [[]]). Ranges are updated via onDidTextDocumentChange event. Once I have the ranges, I can make a call to vscode.window.activeTextEditor.setDecorations(, ranges). This call is made every time the event onDidTextDocumentChange occurs(after range update above). My sql decoration object is initialized like this:
this.sqlLanguageContextDecoration = vscode.window.createTextEditorDecorationType({
overviewRulerLane: vscode.OverviewRulerLane.Right,
isWholeLine: true,
light: {
overviewRulerColor: 'rgba(0,150,225,1)',
backgroundColor: "rgba(0,150,225,0.15)"
},
dark: {
overviewRulerColor: 'rgba(0,80,180,1)',
backgroundColor: "rgba(0,80,180,.15)"
}
});
The syntax highlighting for the sql and groovy contexts occurs in the tmLanguage.json file. If you are curious how that is implemented, let me know!
@daniglas Hi! Can you explain us a bit more how to add those extra settings to VSCode?
Which files we need to edit and where to place those settings you pasted.
I found this sample extension and it seems you're doing something similar to it:
https://github.com/microsoft/vscode-extension-samples/tree/master/decorator-sample
Regards,
+1
Somewhere in this thread it's mentioned there would be problems when text with background is selected. However since nearly every other editor in existence supports background styling this can't be too hard.
E.g. the simplest solution would be just to drop any other background styling when selecting text. This is how Sublime Text does it, I think.
This is how it looks the theme that I use in Atom, and I am very disappointed that I can't get that with VSCode. This kind of customization allows a more subtle and smooth syntax design, because I don't like aggressive designs with saturated colors.
I would love to switch, because I like how VSCode works but I need this feature, it seems very basic to be able to do it. :((((
That style, in Atom has the selection padded a couple pixels larger than the highlighted background (or I guess the background is smaller than selection).
4 years and still going... :(
It's extremely useful for numerous reasons:
- Having textual files (md, txt,...) with white background, while code files have black background
- Files with mixed languages (html, vue, php,...) have sections with different backgrounds
- Important things (h1 in md, flow changers,...) are emphasized
I'm begging you to add this!
+1 Files with multiple embedded languages in them would benefit enormously from having sightly different background colors. It improves readability and makes it easier to switch between contexts.
I'm using the "Highlight" extension in VSCode to get certain parts of the code to have different background colors and/or decorations. All you need to do is use regex and CSS to accomplish this. Nice hack but official background color support would be better!
Any plans to do this? Or any way an outsider can help?
With the addition of semantic highlighting, this is even more useful, as now LSPs can apply modifiers that can be picked up by themes to explicitly color the background. Examples:
- comments (doc vs. inline)
- return points (for languages that support multiple return points)
- Rust's
unsafe - de-activated code (VSCode already does this natively for C/C++ with a drop in opacity, but it would be great for other languages.
- any
async(Rust) or similar sort of closure that will be executed "later", and not inline
And if they exposed to the VSCode theming system, which also controls selection highlights, search highlights, etc, it should be possible for a theme designer to make this all work together as they desire (and then it's also overridable by individual users using settings.json and semanticTokenColorCustomizations
Also keen on this feature. It's really sad it actually works and is just turned off. Can't a priority route just be picked of give us a setting in the color syntax definition to set which background has priority or something. It seems to me a lot of people want this feature so why ignore it?
Between this, File Explorer getting 'Sets', and better bookmark management in Chrome, I cant decide what I want more that devs just dont' want to add even though the code is basically done.
Please?
Having spent some time trying to create a theme from scratch, I better understand what the complication is, but I still think it should be added. There are a LOT of background color interactions already, and it takes a bit of trial and error to figure out how they'll play together.
Some better documentation around the precedence/order that theme categories are applied would help both theme developers, and I think extension developers as well, understand what's going on.
I don't understand yet why this feature was disabled time ago. If the background theming it's only for the editing window this feature won't bother anything because If I enable one theme which doesn't leaves me to read correctly my code I will change it for the previous one, and I will delete it, full stop.
If the problem it's a theme can change the background of the menus and make they not readable, this problem can be easily fixed showing a simple window with a sample menu with the colors of the new theme or a simple window asking if the user can read all correctly, something like windows does when you change resolution of the screen. If you press No they previous theme will be loaded another time....
I'm using the "Highlight" extension in VSCode to get certain parts of the code to have different background colors and/or decorations. All you need to do is use regex and CSS to accomplish this. Nice hack but official background color support would be better!
Thanks for the suggestion, this works well. I also found that if you keep the alpha of the background highlighting low (0.2 or 0.1) then it plays well with with VSCode's native use of background colors.
In two months, it will be five years from this request.
Can't you really make this feature available since it was once available?
It doesn't have to be active by default. Give us a choice, please
Even funnier that there is now background styling – but just for errors... So this feature can't be that hard after all.
In Emacs you can style the background color, is very useful to make top level definitions visually prominent by inverting them. If you select the styled text, then his background color is replaced and the foreground color is changed to contrast with the new one (no alpha blending powers are used!). This is no problem at all, because most of the time you are reading, not selecting. Check this screenshot:
You might laugh, but this is one of two major reasons why I'm still using SublimeText... The other being "search & replace".
What do we have to do? :D
Just ran into this today... I'm replacing ACE Editor with Monaco. The "language" we're writing is a custom, in-house DSL, so it's not even a programming language, just marked-up text with special headers, errors, etc. Background colors are fairly useful for calling the user's attention and dividing what is otherwise monospaced text, so I'm sad to have to remove that feature, since otherwise Monaco is pretty darned awesome.
Or, just give us actual CSS classes based on token names instead of this "mtkXX" stuff and we can do it ourselves...
Would love to see this in too! Especially handy for Markdown code blocks.
Just ran into this today - would really like to see this implemented so that some specific keywords in a programming language can be highlighted with a background colour:
I just ran into this SO Answer suggesting the highlight extension.
A hacky workaround for something that could be native IMHO but it does the job 👍
example:
"highlight.regexes": {
"(//TODO)(:)": [ // A regex will be created from this string, don't forget to double escape it
{ "color": "yellow" }, // Decoration options to apply to the first capturing group, in this case "//TODO"
{ "color": "red" } // Decoration options to apply to the second capturing group, in this case ":"
]
}Just as a reminder, I wanted to highlight the fact that inlay hints are a very great example of:
- How great token background colors do look in the vs code
- They can co-exist with selection color and ...
- The VS Code team itself believes its possible to have token background colors which makes this argument no longer valid:
We had it in, but turned it off as it conflicted badly with the other background decorations we have (selection, word highlighting). — @aeschli
I really think that it becomes the responsibility of the theme author. We can as well set the token colors to the background color of the editor and make the text invisible. But then the user downloads and tries the theme and when they see that issues like these exists, then they go for another theme and write a bad review. VS Code provides almost 100% freedom on what can be accomplished in an extension right now. One has access to the node modules, can create custom editors, can load any binary inside of it, I mean the possibilities are limitless. @Tyriar even made a paint in code! So why when almost everything is possible, limit this one?
Please give this idea another shot. I personally have waited five years for this and came back to it times and time. So imagine how much I personally appreciate it, and I think rest of the community maybe with me on this that they are too are still (after five years) asking you.
Is there really no way to write an extension that adds this feature?
Its hilarious how long this has been here. A basic feature of any modern programming UX refused to be added.
What will be forgotten next? Ability to change fonts? Color? Lets all go back to notepad.
What I don't understand is that why they have kept the issue open. Okay if five years of talking won't convince you then what will? I hate to have my hopes up five years for something no one is going to give any notice. At least close this so we all know once and for all that okay you won't.
Oh, this thread is depressing :(
GitHub seems to need the "😭" reaction too...
What I don't understand is that why they have kept the issue open. Okay if five years of talking won't convince you then what will? I hate to have my hopes up five years for something no one is going to give any notice. At least close this so we all know once and for all that okay you won't.
There's no excuse with this issue, they can place countermeasures for any problem this change can generate. I explained my suggestion time ago on this post: #3429 (comment)
C'mon MS... People are begging you 5 years for this basic feature ffs!
What are the exact problems here? Selection and other bg highlights can just override theme bg color. What could possibly go wrong?!
@NetVicious yeah good point. I guess we have waited and talked for a such a long time, even we are loosing track of all the comments. This is one of the saddest things in the GitHub. At the start I thought as a joke to myself that this is getting so long, we'll wait a decade, and I mean... we actually have waited half that :) Just imagine that :)
We keep the issue open as it is a valid feature request on the backlog. We still have not ruled out to implementing it at some point.
Is it possible to implement this ourselves?
I have a fairly popular color scheme for Sublime that I wanted to port to VSCode because of popular demand, but now I can't without completely redoing all the colors (it has over 400 scopes, about 25% of which have a "background" rule), because "we don't feel like supporting this basic, basic feature."
Nice job, everyone. Goodbye.
We keep the issue open as it is a valid feature request on the backlog. We still have not ruled out to implementing it at some point.
A valid feature? The ability to change fonts can also be called a valid feature. Every basic and highly used feature should be in VS CODE. This is ridiculous. Who is actively in charge of green lighting this? What are their valid reasons for not?
@MattDMo There it's a lot of people waiting to the fix of this issue to change to VSCode.
It's a must for all they, and we don't want to lose that syntax highlighting.
@aeschli out of interest, what would make Microsoft implement this feature quicker, prioritise it faster? More votes? More social media visibility?
@mika76 business value? I don't imagine implementing this feature provides much in the way of overall value for vscode. While it is basic, there is likely only small handful of people that really care about it, and most of those probably aren't choosing other text editors solely for that reason. This leaves little reason to implement such a feature; Presumably the backlog is saturated with more valuable features and they come in at such a rate that it hasn't ever been viable for them to focus on this versus something else. Sadly this isn't solved with simply implementing it ourselves as the same holds true for the revision of PRs....
Is it possible to implement this ourselves?
I can say that with the right CSS overrides, it almost works. The problem is whitespace. Since Monaco positions words rather than using normal whitespace flow, there's no current mechanism to have a background color for whitespace.
In my use case, we still use CSS to make it happen, since we can live without the whitespace also having a background color. But that could be part of the issue for implementation as a proper option, if I had to take a guess.