I was actually going to do this as part of #8985, but it's probably better to submit it separately so it doesn't take as long to merge. :)

Sigh... shame there are all those separate references in core extensions.

@humphd I think for now you'll have to live with just having more diffs in your fork than you'd like... unless you feel like biting off the work of getting extensions' LESS to compile in the context of the Brackets core LESS (or at least with a variable declarations file that's shared between them). That would significantly simplify the dark/light theming too, so it's definitely worth doing... but it's also a lot more work than just adding a dozen extra 1-line diffs on your end :-)

The code changes here look ok to me though. Just one thought: what about the .code-font() mixin defined in brackets_theme_default.less? For completeness we should probably add a @sourceFontFamily-medium variable too, even though there's only that one reference for now.

(Link: the card RESEARCH: Theming improvements & maintainability discusses shared LESS vars briefly, but it covers a lot of other ground too)

@peterflynn thanks for reviewing. I agree that it's not worth shaving the "extensions' LESS" yak just to do this change. I'll do another commit for the .code-font() mixin later today or tomorrow, and this should be good to go.

@peterflynn: Updated, ready for another look.

Looks good.

Awesome, thanks for the help with this, and for landing it so quickly.

FYI, doing follow-up work with this on our branch, I found one more use of SoureCodePro-Medium, but it's in JS here https://github.com/adobe/brackets/blob/master/src/view/ViewCommandHandlers.js#L94. I don't think there's a nice way to include that one in what we did above, so I've just changed it manually in our fork.

Oh that's an interesting rule, too: it relies on two windows-specific fonts (which used to require installing asian languages, but I don't think that's true anymore?) without rules for what to load on OSX and Linux