Add 'workbench.fontFamily' config option

[babakfp]

Hi,

How It Works

This is a super simple PR (only 7 lines) that simply adds a string field option in Settings > Workbench to customize the font-family of the workbench.

It listens for configuration changes and adds the font-family CSS property (with the user-configured value) to the main container of the workbench (.monaco-workbench).

Video Preview

2025-03-09.16-07-32.mp4

Why Accept This PR

• It doesn't harm anyone or break anything.
• It satisfies the simple needs of so many people.
• It improves UX and user satisfaction.
• It reduces negativity, frustration towards vsCode, maintainers and Microsoft Corporation.
• It just gives people what they want.
• It reduces possible risks of users getting infected with malware caused by the action taken to change the font-family of the workbench.
• Users can simply ignore it if it causes issues for them, just like other settings where an option may not work as expected for some users.
• The maintainer who merges this PR will receive many ❤️s :)

Related Issues

• Allow to change the font size and font of the workbench #519 (the PR doesn't close this issue).

---

@bpasero
@isidorn
@alexr00

[flowchartsman]

Considering this only allows adjusting the face, this is only a partial solution to the linked PR, which also mentions size; however, given the tight space constraints, it’s probably better not to let the user set the size arbitrarily, but to set it in the code using an absolute metric based on the existing font size.

I think a good way to do this would be to use something like capsize to get an absolute height measurement for the default workbench font, and then save this in code as the constant value applied to all fonts. This would scale with global zoom, and should hopefully keep things looking more or less how we’re used to seeing then now.

I think it would probably also be nice to have a separate “workspace zoom” setting, using a small selection of pre-chosen unit-less values like [“smallest”, “small”, “normal”, “large”, “largest”] chosen carefully to avoid it getting out of control in either direction j

[bpasero]

How does this PR help for when the picked font is larger than what we expect in certain areas, such as where we hard-code the height of tree or list items?

Just as an example:

vscode/src/vs/workbench/contrib/debug/browser/breakpointsView.ts

Lines 393 to 395 in d8aba06

	getHeight(_element: BreakpointItem): number {
	return 22;
	}

[babakfp]

How does this PR help for when the picked font is larger than what we expect in certain areas, such as where we hard-code the height of tree or list items?

Just as an example:

vscode/src/vs/workbench/contrib/debug/browser/breakpointsView.ts

Lines 393 to 395 in d8aba06

	getHeight(_element: BreakpointItem): number {
	return 22;
	}

It seems that certain parts of VS Code may not be implemented correctly.

These potential issues are unrelated to our current focus.

Users have the option to change the font to achieve their desired appearance.

If a few users experience line height issues, they can simply switch to a different font to resolve it.

I’ve never had any issues after switching to fonts like "JetBrains Mono", "Geist Mono", and others.

[bpasero]

I disagree and would not accept a PR that does not address these issues. If we offer an option to pick a font (and maybe font size), it should work in all components where it applies to.

[babakfp]

I disagree and would not accept a PR that does not address these issues. If we offer an option to pick a font (and maybe font size), it should work in all components where it applies to.

I understand that you disagree, but this decision shouldn't be based solely on personal opinions.

The issue you're bringing up is unrelated to this PR/feature.

For the past 10 years, this highly requested feature has been blocked because of unrelated concerns.

This PR shouldn’t be discarded just because of past styling decisions that caused issues. If those issues matter, they should be addressed separately instead of preventing progress on this.

This PR does not introduce any problems. It’s a simple addition, if font-family changes cause issues for some users, they can simply choose not to use the option, or switch to a different font. I don’t see why this should be a reason to keep blocking it.

I really think the focus should be on moving things forward instead of stalling over unrelated matters. If the line-height issue was truly a priority, it would have been fixed years ago.