Vscode: Selection, highlighting and search colors conflict with each other

[monk-time]

• VSCode Version: Code 1.16.0 (787b31c0474e6165390b5a5989c9619e3e16f953, 2017-09-06T16:27:49.891Z)
• OS Version: Windows_NT x64 6.1.7601
• Extensions:

Extension|Author (truncated)|Version
---|---|---
intellij-idea-keybindings|k--|0.2.13
selectline-statusbar|tom|0.0.2

Reproduces without extensions: Yes

---

Background colors for the editor selection, word highlighting and search matches all conflict with each other in an unexpected way, which seems to be caused by multiple bugs in color priorities and mixing rules.

Text selection color is not restored after searching

The following rules set all three highlighting colors to #FF0000 and text selection to #00FF00 on a black background.

"workbench.colorCustomizations": {
    "editor.background": "#000000",
    "editor.foreground": "#FFFFFF",
    "editor.lineHighlightBackground": "#000000",
    "editor.selectionHighlightBackground": "#FF0000",
    "editor.findMatchBackground": "#FF0000",
    "editor.findMatchHighlightBackground": "#FF0000",
    "editor.findRangeHighlightBackground": "#000000",
    "editor.selectionBackground": "#00FF00",
    "editor.inactiveSelectionBackground": "#00FF00"
}

Normal selection works as expected:

Case 1: put the cursor at the start of the second line and press Ctrl+D ("Add Selection To Next Find Match") three times, none of the three selections become partially or completely green. Since there's no search bar opened, I expect the text selection color to apply here. Pressing Shift+Left to shrink selection re-applies the selection color:

Changing both editor.findMatch* settings to different colors and repeating the steps above doesn't change anything, selected regions are still red.

This is even more confusing if you use the search bar, because multiple cursors for Ctrl+D don't get drawn or animated in that mode (case 2).

Case 3: put the cursor at the start of the file, press Ctrl+F, type "aaa", press Esc (here I expect green color to be applied to the selection, but it doesn't), press Shift+Left. Only then the selection color appears.

This looks a bit different if editor.findMatchBackground is set to #0000FF, but the green color is still not applied after hitting Esc:

Case 4: while "aaa" is still the last searched term, put the cursor at the start of the file, press F3 ("Find Next") and then Esc. This is the only way I could force the green selection color to appear right after using the search:

Case 5: there's something weird going on with the first match. If you repeat the steps from the case above but press F3 several times, after hitting Esc the color of the first match disappears completely:

---

Expected behavior for all cases above: editor.selectionBackground color should be applied to all selected regions when the selection is made without opening the search bar or after it was closed.

Inconsistent blending of findMatch* colors

The following rules set text selection to #303030 (to affect other colors as little as possible), regions with the same content as selection to #FF0000, and current/other search matches to #0000FF/#00FF00.

"workbench.colorCustomizations": {
    "editor.background": "#000000",
    "editor.foreground": "#FFFFFF",
    "editor.lineHighlightBackground": "#000000",
    "editor.selectionHighlightBackground": "#FF0000",
    "editor.findMatchBackground": "#0000FF",
    "editor.findMatchHighlightBackground": "#00FF00",
    "editor.findRangeHighlightBackground": "#000000",
    "editor.selectionBackground": "#303030",
    "editor.inactiveSelectionBackground": "#303030"
}

In this setup, depending on how and where the search bar is opened, the highlighting of matches changes in an unpredictable and seemingly random way.

Case 6: remove the last searched term from the search bar, put the cursor at the start of the file, press Ctrl+F, type "aaa", press Enter or F3 several times. Both editor.findMatch* are blended with alpha 50% with the red editor.selectionHighlightBackground .

Case 7: while "aaa" is the last searched term, put the cursor at the start of the file, press Ctrl+F, then F3 or Enter several times. Unblended green editor.findMatchHighlightBackground appears until you select search matches, then it changes to blended colors from the previous case.

Case 8: while "aaa" is the last searched term, put the cursor at the start of the file and press F3 several times (same as in case 5). All colors are unblended, but editor.findMatch* apply only to the first match.

Case 9: put the cursor at the start of the second line and press F3 several times. None of editor.findMatch* apply at all.

---

In all four cases the expected behavior would be to apply editor.findMatch* correctly no matter how the search was triggered. Also, blending is undocumented and very unexpected: editor.selection* and editor.findMatch* pairs seem to be designed to mirror each other, with each active only in their respective editor mode. But only editor.selectionHighlightBackground is blended with one or both colors from the other pair, and there's no way to influence or override this. Since there are two pairs, blending seems completely unnecessary to me.

[Piping]

add support to change the foreground text color when the text is selected?
Like the setting here in VS Link

[monk-time]

@Piping, that is a different issue. The foreground text is irrelevant here, but that issue was opened by people who like me noticed the low contrast for selected search matches. There are several settings introduced since then, but here I override all of them and still see many irregularities.

The main problems here are that (1) the selection color is not applied when you close the search bar or use Ctrl+D without opening it, (2) editor.findMatch* colors are bugged and (3) blended with another color even when all the relevant colors are provided by the user.

[monk-time]

But thanks for that link, I have found a similar issue https://github.com/Microsoft/vscode/issues/11354. Should I move this post there? That one seems to be more concerned with simplifying the design of configuring selection colors in general, but here I point out the small bugs that cause the current design to work inconsistently.

[alexdima]

@monk-time the root cause here is that all these decorations are rendered on top of each other, because they can all be active at the same time. In the editor "painting" code all these decorations are rendered, but depending on the arbitrary order in which decorations are added to the editor, they will be overimposed.

By using fully opaque colors the decorations end up "hiding" each other. Would it work for you to add a bit of transparency to your decoration colors? Or would you rather expect that we somehow mix those colors when they are overimposed (unclear how?) . e.g.:

"workbench.colorCustomizations": {
    "editor.background": "#000000",
    "editor.foreground": "#FFFFFF",
    "editor.lineHighlightBackground": "#000000",
    "editor.selectionHighlightBackground": "#FF000088",
    "editor.findMatchBackground": "#0000FF88",
    "editor.findMatchHighlightBackground": "#00FF0088",
    "editor.findRangeHighlightBackground": "#00000088",
    "editor.selectionBackground": "#30303088",
    "editor.inactiveSelectionBackground": "#30303088"
}

[monk-time]

@alexandrudima, I understand that decorations are rendered on top of each other, what my post is trying to show is that there are cases where the correct color doesn't get drawn after closing the search bar (selectionBg in cases 1-5) or if the search is triggered in a specific way (cases 6-9). Lots of small bugs here.

Adding transparency is a whole other can of worms that I don't want to open here, because it requires a calculator to reverse-mix multiple colors to figure out how to make the editor show the colors I need, and the above-mentioned bugs turn this into a very frustrating task. This is why I specify only solid colors, but then unexpectedly the editor mixes some of them (selectionHighlightBackground but not selectionBackground) sometimes (cases 6-7) but not always (cases 8-9).

If I don't use transparent colors in my theme, the editor should not mix any of them at all. Mixing should be enabled only for those colors that are either not solid or not specified by the user.

[monk-time]

@alexandrudima, was my feedback helpful? I guess I spent too much time writing this bug report so now I have become way too emotionally invested in its fate, even though it's a minor issue. I hope it didn't sound rude when I referred to what I assumed are bugs as such, if the content of my OP is intended behavior you can close this issue.

[alexdima]

@monk-time I appreciate the fine and detailed steps and your thoughts.

To attempt to improve this, we need a new concept which we currently don't have, that of "recency".

When the view code needs to paint decorations, it doesn't know which one should go on top of which one. The current tie-breaker is "alphabetical" on some internal class names.

In a way, this is as-designed. But I agree, that this could be better if we would have the concept of "recency" in the decorations and use that as a tie-breaker when two decorations need to be painted at the same spot.

[mliq]

My issue is:

1. search all files using searchViewlet
2. open one of the resulting files and do a separate search in the findWidget
3. Results of both searches have the same highlight color - this is not ideal, but not a huge issue. The bothersome issue is: anything that is highlighted by both the original searchViewlet search and the new findWidget search does not get the editor.findMatchBackground color highlight when selected.

I would think that the editor.findMatchBackground highlight should always override any other highlight and wouldn't be a major overhaul to fix? Should this be a separate issue/ticket?

[Chillee]

In VSCodeVim's case, we need to create a fake cursor by using a decoration. However, in certain scenarios, the cursor ends up disappearing due to the fact that it's getting overridden by the selection decoration.

I don't know what a good solution would be, but just wanted to chime in and say that some kind of solution for resolving conflicts in decorations would be nice.

[chibicode]

This (and the lack of support for adjusting foreground color: https://github.com/Microsoft/vscode/issues/36490) seems to be causing headaches for some theme designers:

https://github.com/sdras/night-owl-vscode-theme/issues/90

I found it very hard to make a theme that both looked good and had enough contrast in the selections that made them easily recognizable.

Unfortunately, VSCode doesn't have the ability to inverse the text color or specifically adjust the text color in conjunction with selections.

[mattaningram]

This issue is almost making me switch back to Atom. None of the themes I find have any significant difference between the auto highlights and manual text selection, and for some reason I can't get the auto highlight styling to change no matter what I put in my custom settings.

Can VSCode emulate how Atom handles these effects?

[glen-84]

@alexandrudima,

Instead of a "recency" concept, couldn't you also just have a hard-coded priority order?

1. Decorations added by extensions (f.e. VSCodeVim)
   
   
   
   • Could use recency if there are multiple decorations set by extensions.
   
   
2. User selection (should always be [2nd from] the top)
3. Find match
4. Find match highlight

Am I missing any? Wouldn't that solve most of the issues?

My main issue is not being able to see a selection inside of a find match:

(possibly related to #43928)

@monk-time,

Your issue description is very thorough and well-written. Nicely done.

[mkanet]

Are there any workarounds for this? Not being able to see my selection color on a _find matched_ text makes it hard to know for sure if I've selected the text or not. I'm not sure how other people deal with this.

[123dev]

Here's how I deal with it.
I make Find background totally transparent, but highlight a border.
Same with keywords.
This way selection background color remains intact.

Here are my settings, which works well for Dark+ theme, you might want to change the colors for a light theme.

"workbench.colorCustomizations": {
    // Totally Transparent
    "editor.selectionHighlightBackground": "#ffffff00",
    "editor.findMatchHighlightBackground": "#ffffff00",
    // Borders
    "editor.findMatchBorder": "#ffff00",
    "editor.findMatchHighlightBorder": "#ff0000",
    "editor.selectionHighlightBorder": "#ffffff",
    "editor.lineHighlightBorder": "#272727",
    // Selection
    "editor.selectionBackground": "#771835",
    "editor.wordHighlightBackground": "#771835",
    // Misc
    "editorCursor.foreground": "#00ff00",
    "editor.lineHighlightBackground": "#181818",
    "editor.findMatchBackground": "#000000",
    // Debugger
    "statusBar.debuggingBackground": "#410d18",
    "statusBar.debuggingForeground": "#dddddd"
}