Default editor colors let TextMate shine through

[NTaylorMullen]

Looks like there's a few locations in which C# and us don't provide semantic classifications for the document (it relies on the default editor colors); this ends up showing TextMate colors in unexpected locations. For instance:

@RequestsMenuItems, @(ShowRequests, .Vertical etc. are miss colored.

We may need to re-lobotimize our TextMate theming for attributes 😢

[ryanbrandenburg]

Good catch. This is because Roslyn does not define a color for property name and a few other classifications. They default to the standard color for the Theme, which is "black" for the Light Theme. BUT because the classification didn't apply anything the HTML Classification value is allowed to shine through.

There are two possible solutions here:

1. LSP Tagger respects "Classifications without Coloration" and lets them set the default text value for the theme in that case.
2. Roslyn populates those values. I THINK they could still achieve their current behavior (defaulting to the theme default) using Type="CT_SYSCOLOR" Source="00000008", but I think there's also an argument to be made for explicitly setting the value to black since end-users have no way of knowing what classifications will just default due to empty classifications.

[ryanbrandenburg]

Talked with @gundermanc offline, we both think that 2 is the preferable fix here. @JoeRobich is that acceptable to Roslyn?

[JoeRobich]

Roslyn lists the Identifier classification as the BaseDefinition for our more specific identifier classifications. This allows a single change to the Identifier color to be reflected in all the classifications that do not have special colorization. By setting the foreground for all of our specific Identifier classifications it would be harder for users to configure and would certainly break existing user themes.

[ryanbrandenburg]

Here's what the offending area looks like under Carnation:

The pure "Plain Text" scenario lists no classification at all.