Selection, highlighting and search colors conflict with each other

• 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.

[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"
}

[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.