Over the weekend, I came upon a question on StackOverflow about how, in the new editor, you can't override the foreground color of selected text. I had actually played around with writing an extension to "fix" this awhile back, but never really got it fully working. Reading that question and the, uh, not-so-subtle insults about my teammates and me was enough of a kick in the pants for me to put it up on the gallery.
While I'm at it, I decided to dust off another extension I started working on a few months back, to work around a feature we didn't have time to implement for Visual Studio 2010, which is how the editor draws the background color of text elements.
You can download these on the Visual Studio Gallery:
This is a topic that has come up before; Brittany wrote a blog post about it about half a year ago, and the reaction to that post was mixed. The reaction we've seen, in general, has been positive to the change, but that doesn't mean that everyone is happy with it.
In Visual Studio 2008 (and in most applications), selected text effectively inverts its color when a selection is made. In most apps, that means it goes from black to white, to provide a suitable amount of contrast against the selection color itself.
In Visual Studio 2010, we changed this behavior so that the selected text still appears as if it weren't selected (with syntax highlighting and everything).
There are some useful benefits the new behavior provides:
But one major drawback:
Of course, I'll also point out that this drawback isn't that it is impossible to come up with color choices that provide an acceptable level of contrast when a selection is made; the issue is more that there are existing color schemes that were designed with the VS2008 behavior in mind, and thus won't automatically work well with the new behavior.
Download on the Visual Studio Gallery (source on github)
The extension alleviates this issue by restoring the old behavior and allowing the user to customize the selection foreground color. There are a few caveats, however:
This one is also a change from VS2008, but more in the sense that it was something we didn't have time to get to for this release (we still consider this a bug and not a purposeful change in behavior).
"Colorizers" (language services, effectively) are asked to color a line at a time, and they can provide color information for every character on the line plus one. The last "character" is actually the color information to be used for the whitespace from the right of the line to the right of the viewport.
While the default VS color scheme doesn't use this, you can see the effect by changing the background color of the various XML Doc comment parts.
Without the extension, though, there are two problems, which you'll discover immediately if you change the background color of any types:
Here's a screenshot of what it looks like with the extension:
As the screenshot shows, the extension basically fixes both issues, though it doesn't do so perfectly. As I mentioned before, colorizers have the option to specify the color for the space past the end of the line, and that's what the editor uses to draw that portion (in Visual Studio 2008). Unfortunately, this extension doesn't have access to that information, and so the best it can do is guess that the background color of the last character on a line should be the same as the empty space after the character. This is, of course, not really true in all cases; if you give keywords a background color and happen to end a line with a keyword, you really don't want that background color to continue past the end of the text. Still, the behavior works in the case where you only set the background color for text that you want to continue past the end of lines (as many of these color schemes do).