We have the settings editor.fontFamily and editor.fontSize, but I'm missing an editor.fontWeight. This is most needed when using a dark theme, as folds become visually bolder in that setting. Compare for example Code using Input Mono (regular):

with Sublime Text using Input Mono Thin:

This could be either accomplished by a weight setting similar to the CSS font-weight, or as part of the font name (i.e. Sublime text accepts "Input Mono Thin" as the font name, while Code currently rejects that).
Oh, and kudos for creating an editor experience to rival the best on Mac! I never thought the day would come when I'd run a Visual Studio product on Mac, but I'm happy to be proven wrong!
Thank you for the kind words. Will look into adding this
@calmh While waiting for this, there is a workaround for us OS X users, as seen on this Issue from Atom: https://github.com/atom/atom/issues/3790
(Basically, strip spaces, and put a hyphen between the font name and the weight, so InputMono-Thin in your case. I use Source Code Pro Light myself, and so setting it to SourceCodePro-Light works for me)
Oh! Neat! I had resorted to disabling the variants except thin and bold in font book. :)
Any hope for a windows workaround or fix? Can't set bold fonts as of v0.10.11
Hi, any updates on this? Some fonts look better when they are bold, an "editor.fontWeight" or "editor.fontStyle" setting would be awesome!
Thanks
Consolas (the default monospace typeface for Windows) appears bold in VSC for some reason, but others don't.
This feature is really a deal breakeer for me. Any news on this? @alexandrudima
PR welcome, IMHO it is straight-forward to implement by following the fontFamily or fontSize settings.
fwiw, I started work on this by implementing the "fontWeight" setting.
I had to stop for a bit since at the time, current master did not work correctly for the terminal panes, I will continue work in the next weeks after my vacation.
馃拑
Hi guys, submitted a PR for this issue. Please let me know if there are any issues.
Your solution works better than the one I was working on @ramamurthynagaraj thanks!
I think this issue can now be closed?
Thank you @ramamurthynagaraj
Hi, thank for the update.
Unfortunately, there is still an issue as you can see in the screenshot below; even the thinnest fontWeight is a little bold (font used : Consolas on windows 8). Same result with an integer font.
The font in sublimetext at the top and the vscode one at the bottom.

@vavans This might be caused by different font rendering engines. I don't know what Sublime uses, but our font rendering is ultimately done by Chromium. It is not clear to me if Consolas has the exact weight of 100 or some fallback logic is used by Chromium (as is described in https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight)
Same here. 150% scaling on 2160p screen, 14pt Consolas appears a bit boldish, even with 400 or normal. Light or anywhere below 400 won't make any difference. When you look close to display it's nice and beatiful, but from 0,7-0,8 m. from display it looks like Fixedsys....
Also not work for me (OS X EI Capitan 10.11.5, VS Code 1.5.1). No difference between font weight "300" and "normal".
@mouhong Is there any difference for you in Chrome if you try it in a jsfiddle like https://jsfiddle.net/rhy7v1wp/
If not, then please create an issue against Chromium https://bugs.chromium.org/p/chromium/issues/list and link back to it here.
Thank you!
@mouhong Perhaps we can expose -webkit-font-smoothing: antialiased; in the form of a setting, I don't believe that works well for all folks across all OSes and across all fonts.
@alexandrudima I found that, if I inspect your GitHub comment in Chrome, and manually set style font-weight: 300, the font will get thinner. Interesting.
One thing to keep in mind is that I am on Chrome 53, while VSCode is on Chromium 49, so that might have an impact too.
@alexandrudima
Doesn't work for me
Version 1.5.3 (1.5.3)
5be4091987a98e3870d89d630eb87be6d9bafd27

I am trying different values, but font looks the same

Also it would be great to add list of possible values from editor.fontWeight in Default Settings file. Now user has to read PR/codebase to understand what is acceptable
It does work. It's just Consolas doesn't have light version. Don't know where to report it. But, i think, MS employees here could forward it to font devs.
are we able to expose -webkit-font-smoothing: antialiased so we can get a better rendering on macOS?
@Wong
Until we have Consolas Light alternatively you can use Source Code Pro from Adobe.
https://github.com/adobe-fonts/source-code-pro/releases
@regs01 I was using Operator Mono. I found a way to make it work without explicitly setting fontWeight. I used OperatorMono-Light for family which helped set the correct fontWeight. Thanks.
Hi everyone.
@alexandrudima What confused me is what comments are rendered with a font weigth more lighter that the rest of the code. Is it some config that you guys pass to chromium to render this way? I think if all the code render with the same weigth of comments, everybody will be happy. some idea?

I'd like to hope that @gabrielnogueira is onto something here. Can anybody (no pun intended) comment on that?
Part of the perceived font-weight is related to contrast between background and the font itself. For example the Monokai is quite unbearable, font colors are rather bright on dark background. Bright letters are using more sub-pixels and thus creating the too-bold-font perception. I've switched to Atom One Dark theme and everything looks better now. Even VS Code own softer Color Themes look better (Monokai Dimmed etc). And for the comment that comments are rendered lighter - as comments are dimmer, they are using (visually) less sub-pixels thus they are visually lighter.
@TanelS Thanks for the explanation. Although, comparing the same font + background on VS Code (left) and cmder (right), they display very differently, and cmder looks much more crisp. Is this entirely the fault of how chrome renders fonts?

@austinthiel VSCode uses Electron as rendering engine. And most of the font anomalies are because of that. Hopefully the Electron devs are able to handle the font-weight problems. Meanwhile I personally use less contrasted color themes as a workaround.
I see that now. I chose the font + background on another Electron app and it's got that same fuzz-factor to it. That's a bummer, I hope it's resolved soon.
Edit: If anybody's looking for a decent crisp-looking font, try Inconsolata
Most helpful comment
@calmh While waiting for this, there is a workaround for us OS X users, as seen on this Issue from Atom: https://github.com/atom/atom/issues/3790
(Basically, strip spaces, and put a hyphen between the font name and the weight, so InputMono-Thin in your case. I use Source Code Pro Light myself, and so setting it to SourceCodePro-Light works for me)