Add a highlighting rule for mapping keys to the default color schemes

[jwortmann]

Problem description

The default syntax packages have adopted the scopes meta.mapping.key string for string keys and meta.mapping.value string for string values in mapping-like structures in most situations, see e.g. sublimehq/Packages#862, sublimehq/Packages#2020. This is good from a color scheme perspective, because they only need to target a single scope to achieve nice highlighting in plenty of languages if they want to distinguish between keys and values. Unfortunately, none of the default color schemes target these scopes, which results in suboptimal highlighting and hard to grasp structures in large and especially nested mappings. The default highlighting for JSON files probably suffers the most from this problem. And the missing distinction of keys and values in the default schemes can also be an obstruction for 3rd-party packages to follow the scoping conventions mentioned above, because authors might want to use unconventional scopes for mapping-like structures instead to achieve better highlighting there. Of course it strongly depends on each own preferences what exactly good highlighting style is in their opinion, but I've checked the default themes in the VS Code, Atom and Brackets editors, and all of them distinguish between key and value highlighting at least for JSON files.

Preferred solution

I propose to add a rule for meta.mapping.key string to the default color schemes, with a foreground color distinct from the color used for string. What exact color to use would have to be decided for each scheme individually, but since such a decision would also effect string keys in e.g. JavaScript objects and Python dicts, it probably should not be a color used for keyword or other frequently occurring scopes like support or variable.function.

Here is a comparison example in Monokai with default highlighting for JSON, and after adjusting the color for keys to orange (which is otherwise used for variable.language and variable.parameter in Monokai):

Alternative 1

Use "font_style": "italic" instead of a foreground color. No big improvement gained with this though, imo.

Alternative 2

In case of reusing an existing highlighting color would be seen as too confusing for JavaScript, Python, etc., instead apply the distinct color to meta.mapping.key.json string, i.e. only to JSON files. This wouldn't solve the problem for 3rd-party packages though, which would like to distinguish between keys and values in most color schemes while using the recommended scopes.

Additional Request

Consider adding a description about meta.mapping.key and meta.mapping.value for mappings/dicts/objects to the scope naming guidelines, to improve adoption in 3rd-party packages.

[deathaxe]

I find this a quite important change as it currently appears ST wouldn't support syntax highlighting in JSON as it used to do before the changes to meta.mapping.

[levonet]

There’s no point acting all surprised about it. All the planning charts and demolition orders have been on display in your local planning department in Alpha Centauri for fifty of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now.

There are already many surprised people sublimehq/Packages#3288, and there will be more of them. Is it possible to roll back these changes to the previous state, as the monotonous look of YAML is very uncomfortable.

[VioletGiraffe]

+1 to this, YAML syntax highlighting is broken and it's an obvious bug in Sublime 3, still not fixed.