Editor selection colors should be simplified

[Tyriar]

• VSCode Version: Code - Insiders 1.5.0-insider (1de4d83, 2016-08-31T06:16:16.953Z)
• OS Version: Linux x64 4.4.0-36-generic, Ubuntu 16.04

Follow up from #1636

I think we need to take a step back and take a good look at editor selection colors. Currently there are so many states, it's very confusing as to what find match, selection match is what and even what the actual selection is.

Here are some of the states using my theme Glacier:

Selection
Find match
Symbol match
Selection match (lighter than word match)
Selection + selection match
Selection + find match + symbol match
Symbol highlight
"Strong" symbol highlight for cursor word
"Strong" symbol highlight for words away from cursor
Selection + "Strong" symbol highlight for cursor word
Selection + "Strong" symbol highlight for cursor word (when selecting via ctrl+d)
Selection + "Strong" symbol highlight for cursor word (when selecting via ctrl+d) + Find match

This is in no way an exhaustive list of states but I think it gets the point across. Here are some of my initial thoughts:

• The actual selection should always be the selection color defined in the theme - this is the primary reason I sometimes lost my selection.
• Find matches should not use the selection color defined by the theme.
• Some of these states have colors that differ by so little they lose information and make the UI look sloppy. We should reduce the number of possible colors by reducing the amount they can stack with each other.
• Is it useful differentiating symbol highlight and selection highlight?
• Is strong symbol highlight useful? We already have a color to indicate symbols and they can't both show at once.

  • I'm quite perplexed by it, especially when things like this happen:

    

    Why are both userEnv variables highlighted with the strong symbol highlight below but not above?

    

  • The blue looks bad in my theme, is there a way we can get a more suitable color using existing colors?

• The line highlight color doesn't work when a range is selected.
• Can we use a border to indicate find matches or something? That would make the distinction very clear.
• Since 95% of themes are just imported from Sublime .tmTheme files and not adjusted to work better with vscode, we should make an effort to have the defaults work and only add additional tmTheme properties if they are absolutely necessary.
• findHighlight is defined in many themes, why don't we adopt that since Sublime uses it?

Personally I think something like below would be more usable despite being so simple (this is to illustrate my point, I'm not proposing this):

• Selection is always the selection color from theme
• All symbol and word highlights are selection color at 50% opacity
• Find matches use white with 50% opacity

[sandy081]

@Tyriar Thanks a lot for bringing up the issues with colors and providing some suggestions. I agree that we have many color contrubutions and they get mix and matched. Please see Editor Decorations & Colors wiki which me and @alexandrudima came up with.

Problem 1:

Most of them define new colors and some reuse already defined. They should be defined such a way that they look good when applied individually with the given background. Otherwise, we have to go and fix them. As they are dependent on the theme (background etc), its hard to fix them for all themes. Hence, as a first step we fix them in our defaults and extract them as custom TM settings (just like Sublime) which fixes this problem.

I tried to map the new settings as much with Sublime defined ones, but we differ a lot in usage. For eg: Sublime uses color value of findHighlight setting for highlighting find match, but we use that color for highlighting the line of find match, go to line (as range highlight). So using those settings will give us un expected and un wanted results. Hence, we defined our own settings which is also good IMO. Users having issues with some colors in themes can always create an issue against the theme.

Problem 2:

When more than one functionalities overlap, we have unexpected colors. For eg: Find + Select or Select + Wordhighlight. We do not have a proper solution for this and may be I think we need UX assistance to tackle this.

[Tyriar]

Why don't we try to align more with how Sublime behaves considering that's what the majority of the themes were designed for? findHighlight seems like a prime example of something we should align with, this is something that my theme defines but it isn't used.

I don't think the suggestion that users can just create an issue against the theme is realistic. To give an example, of the 10 top themes in the marketplace:

• 4 of them are closed source, or at least have no link to a repository. This includes the number 1 theme which I've attempted to hunt down in the past.
• 4 of them are Microsoft's which we've largely stopped maintaining in favor of community themes.

[bgashler1]

@Tyriar I like the idea of making Sublime themes compatible with our product out of the box. It's less hassle for users and theme-makers.

@Tyriar @sandy081 Let's talk about this at UX sync tomorrow morning, if you can attend.

[alexdima]

My 2 cents:

• Sublime has added "Sublime specific" keys to the TextMate themes because it has concepts which don't exist in TextMate
• we have concepts which don't exist in Sublime or if there exists a similar concept, it is unapplicable. e.g. Sublime uses findHighlight color to render a border around find matches, we can't render borders on our decorations because we render multiline decorations by rendering a patch for each line because we don't do the text layout, etc. We cannot take a border color and use it as a background, it will look bad.
• IMHO we will not get a 100% great looking theme by simply importing Sublime themes, similarly to how Sublime did not get 100% great looking themes until folks started creating them for Sublime specifically.
• I see this as an opportunity to document our "VSCode specific" keys and invite passionate community members to go and tweak themes with VSCode in mind. We can perhaps detect if a theme has VSCode specific keys and sort it to the top when searching in the marketplace or add a badge "VSCode tweaked" or whatever

[mzamoras]

Hi I would like to share my point of view.

1. Sublime themes are some how hard to edit or create, unless you use the creator page https://tmtheme-editor.herokuapp.com, is boring, difficult and has some issues with preview.
2. I suggest an Atom approach, why don't transform or parse sublime into css, sass or less, in that way the user has a base with the theme but would be easier to make adjustments. I suspect that more users are going to be willing to cooperate with the theme creation. It's easier and in the end it's going to be transform into a css stylesheet.
3. I love VsCode, super fast, clean, unobtrusive, intuitive, etc, but every time I try to code in it, something doesn't feel right with the sidebar. PHPStorm had the same problem with customizing sidebar until some one made a hack, now every theme is using it. No matter how beautiful a theme is, the sidebar makes it awkward, try material theme for example, even the Microsoft one looks awful. The only one looking incredible is the lighter one, with the white sidebar.( personal taste ).
4. On every theme I have used, there are slightly fixes I'd like to make, why don't let the final user make some fixes or tweaks as atom?, with the stylesheet that loads over the theme.
5. A visual editor would be awesome.

Thanks, and keep the great work!

[sandy081]

@Tyriar @bgashler1 As I mentioned in my (previous comment)[https://github.com//issues/11354#issuecomment-244065261] that I tried to match our keys/colors/behavior with those of Sublime. But they are not one-to-one. Refer here for Sublime color settings

To be aligned with Sublime specific keys, we have to change our UI representations. Also we have new concepts which I think Sublime does not have. Hence, I am not in favor of this.

Also note that, we aligned with some settings with Sublime which are in sync with VS Code.

I agree with @alexandrudima to have VS Code specific color settings.

[aeschli]

+1 on @alexandrudima comment. While we have a easy way to start authoring a theme by importing an existing one from sublime or text mate, adaptation is required as there are feature differences between the products. Some of these feature differences are intended, some are given by the underlying architecture. Therefore also themes will not be interchangeable by products. This never was a goal, and should not become one. It's the same with Sublime customizing TextMate themes, or Atom customizing TextMate and Sublime themes.

What I think would be great if the UX team could document and maybe simplify the different colors we use in our UI and the concept behind them (selection color, input border color, focus border color....). Not just in the editor and its contributions, but also in the workbench. I think there is a lot of potential of unifying the colors of the various widgets. The goal of this would be a more consistent UI as well as making it possible to theme the workbench (not just the editor).

[Tyriar]

I think the Sublime theme compatibility topic is largely closed which is fine, let's commit to these new properties and document them to increase visibility to theme authors. So there are still a few more actions that should be taken/discussed:

• Have UX look at the complexity of the highlight/selection colors (tracked in this issue)
• Document theme creation and custom properties Explain theme creation and vscode-specific tmTheme properties in extensibility reference vscode-docs#561
• Can we warn when importing tmTheme files that contain unsupported global properties to make what is required in adapting a theme more obvious? Warn on unsupported theme properties when importing a tmTheme vscode-generator-code#45

I've started making a few PRs to themes (MS and external) to make them more presentable in the marketplace (repo links, screenshots, preview, etc.) to tackle a related problem with themes.

Thanks all for having this discussion, this will help a lot with the issues I've been experiencing trying to build my own theme.

[millionbonus]

After all, as a text editor rather than a neon displayer.
I think we just need fewer kind of highlight such as selection, current line and find match. Then it is just enough, isn't it

[DaveEveritt]

I'm commenting here (as a daily VS Code user only, not a developer) because I found an earlier closed issue (Selection and selection matches highlight color #1636) - i.e. if you actually select some text, it's indistinguishable from the highlight used for matched code pairs, or matches to the current word at the cursor position.

If the system-wide highlight colour (when selecting any text system-wide) isn't portable to VS Code, I need a way to edit it in a user-generated 'override css' file or something (like user settings), which appears to be impossible without creating a new theme. I'm using 'Dark'.

Just to make sure I'm not missing something, I posted this as a question on StackOverflow

[FabioAntunes]

Is there a way for disabling selection matches for the time being? I started using VS code today and it's possible to distinguish my selections. In this screenshot the first this is selected while the others are highlighted. It's just impossible for me to know when I selected something

[iulo]

@FabioAntunes
in user settings :
"editor.selectionHighlight": false

[iulo]

any update?
How about use border with match select like atom?

[FabioAntunes]

@iulo have you looked at the screenshot? That's what's on my configs on the right