Consolas doesn't have good-looking italics, really just because fixed width fonts generally look bad italicized. The fixed width lucida fonts would have been equally as bad to read :-/ I'm not sure that's an arrogant thing to point out, though I did get a laugh out of you taking the time to call both the comment asinine and point it out on a public review site, so thanks for that :-p
I like this extension very much. This awful hard-coded font, however, is a no-go! PLEASE make it configurable, or at least don't change the VS default font. As it seems, not many people share your taste...
The addin works just well, but we do not apparently share the same taste with the author (I like italic consolas). My suggestion: italicize the font configured in Visual Studio text configuration instead of using hard-coded Lucida sans.
I get this error in VS2012 when opening a .cs file containing comments:
<source>Editor or Editor Extension</source>
<description>System.ArgumentOutOfRangeException: size should be positive or null
Parameter name: size
at Microsoft.VisualStudio.Text.Formatting.TextFormattingRunProperties..ctor(Brush foreground, Brush background, Typeface typeface, Nullable`1 size, Nullable`1 hintingSize, TextDecorationCollection textDecorations, TextEffectCollection textEffects, CultureInfo cultureInfo)
at Microsoft.VisualStudio.Text.Classification.Implementation.ClassificationFormatMap.CreateTFRPFromRD(ResourceDictionary dictionary)
at Microsoft.VisualStudio.Text.Classification.Implementation.ClassificationFormatMap.GetTextProperties(IClassificationType classificationType)
at Microsoft.VisualStudio.Text.Classification.Implementation.ViewSpecificFormatMap.GetTextProperties(IClassificationType classificationType)
at ItalicComments.FormatMapWatcher.Italicize(IClassificationType classification)
at ItalicComments.FormatMapWatcher..ctor(ITextView view, IClassificationFormatMap formatMap, IClassificationTypeRegistryService typeRegistry)
at Microsoft.VisualStudio.Utilities.PropertyCollection.GetOrCreateSingletonProperty[T](Object key, Func`1 creator)
at ItalicComments.ViewCreationListener.TextViewCreated(IWpfTextView textView)
at Microsoft.VisualStudio.Text.Utilities.GuardedOperations.CallExtensionPoint(Object errorSource, Action call)</description>
I'm not sure if/when I'll get around to updating it. You can enable it for VS2012:
1) Download the extension
2) Change the file extension to .zip and unzip the contents
3) Modify the extension.vsixmanifest, adding a new entry under the SupportedProducts group:
<!-- VS10.0 is here, below it add: -->
4) Add everything back to a .zip file, change the extension to .vsix, and open it from explorer
I would suggest grabbing the code for this (http://github.com/noahric/italiccomments) and modifying it to pick a different font (or just not override the font). Look here for the code that sets the font:
Here's what I did to keep the font the same as the VS default:
- Download the source from github (as mentioned by Noah above)
- Make sure you have the Visual Studio SDK installed
- Load the solution
- Change line 129 to read:
var newTypeface = new Typeface(properties.Typeface.FontFamily, FontStyles.Italic, FontWeights.Normal, typeface.Stretch);
- Go to bin\Release (assuming you built as a Release build)
- There's your new vsix
I use this extension a longer time, but it is annoying reading /**...*/ doxygen comments, where this extension does NOT format the spaces before the start of the comment block, while it formats the leading spaces of each line in the rest of the comment block.
Is it possible, that this extension ignores in a comment block the "leading" spaces (^[[:space:]]+)?
It's possible, but it isn't that simple. The extension doesn't re-classify comments, it changes the formatting information for comments themselves. The reason why it looks crappy in that case is because the language service itself is classifying that whitespace as a comment, and the extension can't change that.
However, this extension (or another) could have a separate classifier that only classifies the whitespace at the beginning of lines to try and override any font face/size changes. The problem there is that there isn't a static way of declaring the formatting information for this classifier to override/undo lower-priority formats to be the same value as a different format (i.e. plain text). It would have to hardcode the default font face/size and then write a component that watches for changes to the default and applies that to the whitespace override format.
That's a pretty longwinded excuse, I know :-/ I'll be pretty busy the next few weeks, so I don't know if I'll get to look into anytime soon, but I'll try to find some time.
Thanks for your feedback :)