[Test item] Try using the new diagnostics tag API #52218
Comments
mjbvz
changed the title
|
Is there any way to still use the previous behavior of graying out the code instead of fading it and keeping the syntax color? I understand from #51104 that a lot of folks like this version. However having tried it out in insiders, I find the previous grayed out version to be much easier to scan for. (I tried the borders setting and it was too noisy). |
|
No, no current plans for an option to revert to the old behavior. The new effect is more subtile but does retain useful coloring information in the faded out spans |
|
@mjbvz What do you mean by |
This commit allows users to set a color for unused code which had been an unconfigurable behavior (defaulting to a shade of gray) until microsoft#51104 / microsoft#52218 when it was replaced with setting that allows for either decreasing the unused token's opacity while preserving its color and/or setting the color of a 2px dashed border that "underlines" the unused token. The previous behavior avoided some contrast issues introduced by microsoft#51104 / microsoft#52218 when reducing the opacity of some syntax colors that were already at or just over the low-contrast frontier into squintland, the unlegible country, a place no programmer should be forced gaze. Conversely, tokens that don't contrast enough with themselves won't scan well when the programmer is looking for unused tokens.
Test for #51104
Complexity: 3
Summary
#51104 introduces a new
tagsfield on diagnostics. This field is used to add additional metadata about the diagnostic. We currently use it to mark unnecessary code so that it can be rendered as faded out.Testing
Try using the new tags api extension that contributes diagnostics. Things to try:
...on suggestion diagnostics but not disable squiggles on errors and warnings."editorUnnecessaryCode.opacity"and"editorUnnecessaryCode.border"(for high contrast) as described in the api documentationThe text was updated successfully, but these errors were encountered: