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.

[SeanHub]

Very nice addition, nice job @babakfp. Lets get it merged!

[natalia-legarska]

@babakfp Could you please add font size too? I'd love to see that in vs code <3

[babakfp]

@babakfp Could you please add font size too? I'd love to see that in vs code <3

If I remember correctly, there was an attempt at adding a font-size control to the workbench, but it didn't get anywhere.

The goal is that, they accept this PR, and later I'll do:

If this PR gets through, I'll follow up with another one that lets you add custom CSS and JS to the workbench. This will give you full customization control, without having to wait for new options or rely on hacky extensions.

#519 (comment)

[flowchartsman]

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

While I myself am one of the people that has wanted this feature for a long time and have been frustrated that it hasn't happened yet, let me play devil's advocate here for a second: when a high-demand issue has been open for a long time, it doesn't necessarily mean that no one on the project side cares about the issue. If it did, it would be summarily closed, and we all know this team has no problem doing that. Usually it means that the priority of the issue is mismatched with how easy it is to fix.

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.

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

These potential issues are unrelated to our current focus.

This is not the best way to move a PR forward. A non-trivial problem demands a non-trivial solution, and sometimes you have to deal with the constraints that make it non-trivial. In its current form your PR adds a single setting, which is a trivial thing to add. It doesn't demonstrate any attempt to understand why the issue is unaddressed or what the knock-on effects of the change might be. Maybe you have done some of this work already, but I can't tell from the PR, so you should mention it if you have. If the fix were truly this simple, I would think it would have been done by now.

While @bpasero may not have phrased it in positive terms, he is actually helping you here. He has clearly spelled out at least one major constraint that must be addressed for this feature to land, namely that there are places where the size of elements is hard-coded. This is a not the easiest constraint to solve for fonts, which use relative metrics and tricky bounding boxes. Most of the common CSS attributes for specifying font size do not address precision well for this reason.

PRs for tricky issues need to start with a measure of effort to understand why they are tricky and demonstrate at least the beginnings of a comprehensive fix before they can pick up momentum. You don't need to address everything at first, but, as a maintainer myself, if I see a PR come in for an issue that shows a decent amount of upfront effort, I will be much more inclined to jump in and give additional direction to help it get to where it needs to be.

Let's go over your bullet points from the perspective of a project maintainer and see where we sit:

---

• It doesn't harm anyone or break anything.

You need to demonstrate this as best you can. A video is not a great medium for this, given how difficult it is to navigate and how compression can affect the fidelity of the image. This is a graphical fix, and it needs screenshots demonstrating the effects of the change. Even as a potential user, I would want to see clear before-and-after screenshots of various UI components, ideally with at least two fonts of different visual presentation (think monospace vs. proportional, serif vs. sans, etc). A perfect first candidate for this, now that you've teased it out is the one a project member mentioned by name earlier in this very thread.

• It satisfies the simple needs of so many people.

This PR does not satisfy my needs, and I think my needs are simple: I would want the ability to change the font size at the very least, and I'd be willing to bet that's true for most of the users that want this. This PR does not provide that setting. Why not? The burden is on you here to anticipate needs and address them. I'm not seeing that here yet and as a user I would not want this merged.

• It improves UX and user satisfaction.

• For "improves UX", see above.
• For "user satisfaction" short of a case study you can't prove this. All you know is that some nontrivial number of users want to be able to change the font and are frustrated that they can't. But many of those same users would be just as dissatisfied with a solution that didn't work well, and the complaints would continue. Except they likely wouldn't be addressed to you, they'd be addressed to the maintainers. No one wants that.

• It reduces negativity, frustration towards vsCode, maintainers and Microsoft Corporation.

This is not a technical merit, and is kind of glib and adversarial. If I were a maintainer, I would read this and think you were not approaching the issue with a collaborative mindset, and I would be wary of chiming in with additional constraints and requests for fear you wouldn't take them constructively and would be difficult to work with. This would just waste my time and make me feel bad.

• It just gives people what they want.

Users know they want to change the font. They don't know what that entails or what might make the feature difficult. As the feature designer, it's your job to consider these concerns upfront as best you can, and to solicit feedback and collaboration on the parts you might not be clear on.

• It reduces possible risks of users getting infected with malware caused by the action taken to change the font-family of the workbench.

I'm not sure how often this happens, but it's a strongly negative motivator and that doesn't usually work well when proposing a feature, especially without hard numbers. Best to leave it out.

• 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.

You should write your features from the perspective that most users will either consider it a positive addition or at the very least a neutral one. A bullet point that is essentially "if it sucks, they can just ignore it" is the opposite of a selling point. It's a red flag. Fixing or migrating an existing, buggy feature is much harder than not adding it in the first place.

• The maintainer who merges this PR will receive many ❤️s :)

So would the submitter that merges a good fix! This could be you!

---

Please understand that I'm not trying to be overly critical of you here. I'd love to see this change, and I want to see you succeed. I respect the desire to jump in and get things done. Hopefully you can keep that energy going and move this thing forward.

[niamleeson]

While I also think that the PR description feels hand-wavy, this PR is being blocked for all kinds of philosophical reasons instead of moving toward a solution. This PR clearly states it isn't intended to close all the issues from the original thread, and instead it states it is just adding one option. Not sure why both @dpasero and @flowchartsman are asking for the ability to change font sizes when this PR is clearly limited to be about font-family.

[Esteban-Rocha]

Please understand that I'm not trying to be overly critical of you here. I'd love to see this change, and I want to see you succeed. I respect the desire to jump in and get things done. Hopefully you can keep that energy going and move this thing forward.

Nonsense gatekeeping. Merge this already it is needed.

[mrnzdev]

Leaving my comment here hoping that this will get merged some day...

[Serpentarius13]

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

While I myself am one of the people that has wanted this feature for a long time and have been frustrated that it hasn't happened yet, let me play devil's advocate here for a second: when a high-demand issue has been open for a long time, it doesn't necessarily mean that no one on the project side cares about the issue. If it did, it would be summarily closed, and we all know this team has no problem doing that. Usually it means that the priority of the issue is mismatched with how easy it is to fix.

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.

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

These potential issues are unrelated to our current focus.

This is not the best way to move a PR forward. A non-trivial problem demands a non-trivial solution, and sometimes you have to deal with the constraints that make it non-trivial. In its current form your PR adds a single setting, which is a trivial thing to add. It doesn't demonstrate any attempt to understand why the issue is unaddressed or what the knock-on effects of the change might be. Maybe you have done some of this work already, but I can't tell from the PR, so you should mention it if you have. If the fix were truly this simple, I would think it would have been done by now.

While @bpasero may not have phrased it in positive terms, he is actually helping you here. He has clearly spelled out at least one major constraint that must be addressed for this feature to land, namely that there are places where the size of elements is hard-coded. This is a not the easiest constraint to solve for fonts, which use relative metrics and tricky bounding boxes. Most of the common CSS attributes for specifying font size do not address precision well for this reason.

PRs for tricky issues need to start with a measure of effort to understand why they are tricky and demonstrate at least the beginnings of a comprehensive fix before they can pick up momentum. You don't need to address everything at first, but, as a maintainer myself, if I see a PR come in for an issue that shows a decent amount of upfront effort, I will be much more inclined to jump in and give additional direction to help it get to where it needs to be.

Let's go over your bullet points from the perspective of a project maintainer and see where we sit:

• It doesn't harm anyone or break anything.

You need to demonstrate this as best you can. A video is not a great medium for this, given how difficult it is to navigate and how compression can affect the fidelity of the image. This is a graphical fix, and it needs screenshots demonstrating the effects of the change. Even as a potential user, I would want to see clear before-and-after screenshots of various UI components, ideally with at least two fonts of different visual presentation (think monospace vs. proportional, serif vs. sans, etc). A perfect first candidate for this, now that you've teased it out is the one a project member mentioned by name earlier in this very thread.

• It satisfies the simple needs of so many people.

This PR does not satisfy my needs, and I think my needs are simple: I would want the ability to change the font size at the very least, and I'd be willing to bet that's true for most of the users that want this. This PR does not provide that setting. Why not? The burden is on you here to anticipate needs and address them. I'm not seeing that here yet and as a user I would not want this merged.

• It improves UX and user satisfaction.

• For "improves UX", see above.
• For "user satisfaction" short of a case study you can't prove this. All you know is that some nontrivial number of users want to be able to change the font and are frustrated that they can't. But many of those same users would be just as dissatisfied with a solution that didn't work well, and the complaints would continue. Except they likely wouldn't be addressed to you, they'd be addressed to the maintainers. No one wants that.

• It reduces negativity, frustration towards vsCode, maintainers and Microsoft Corporation.

This is not a technical merit, and is kind of glib and adversarial. If I were a maintainer, I would read this and think you were not approaching the issue with a collaborative mindset, and I would be wary of chiming in with additional constraints and requests for fear you wouldn't take them constructively and would be difficult to work with. This would just waste my time and make me feel bad.

• It just gives people what they want.

Users know they want to change the font. They don't know what that entails or what might make the feature difficult. As the feature designer, it's your job to consider these concerns upfront as best you can, and to solicit feedback and collaboration on the parts you might not be clear on.

• It reduces possible risks of users getting infected with malware caused by the action taken to change the font-family of the workbench.

I'm not sure how often this happens, but it's a strongly negative motivator and that doesn't usually work well when proposing a feature, especially without hard numbers. Best to leave it out.

• 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.

You should write your features from the perspective that most users will either consider it a positive addition or at the very least a neutral one. A bullet point that is essentially "if it sucks, they can just ignore it" is the opposite of a selling point. It's a red flag. Fixing or migrating an existing, buggy feature is much harder than not adding it in the first place.

• The maintainer who merges this PR will receive many ❤️s :)

So would the submitter that merges a good fix! This could be you!

Please understand that I'm not trying to be overly critical of you here. I'd love to see this change, and I want to see you succeed. I respect the desire to jump in and get things done. Hopefully you can keep that energy going and move this thing forward.

I have started to read your reply with an agreement, but it went downhill quickly. You propose points that feel like this product is something to be sold for prestigious customers that will throw tables at you if the feature doesn't work. The fact is, people are already throwing tables and the PR starter had straightforwardly mentioned so. There is surely no harm done to accept this PR just this very second to be included in the next release, because it is an optional feature. It could be labelled "experimental" per this:

Features and their corresponding settings can be in one of the following states. Depending on the state, you might be cautious about using the feature or setting in your workflow.
Experimental - Exploratory features available for early adopters. These features might change or be removed in the future. In the Settings editor, these settings have an Experimental label. You can also search experimental settings by entering @tag:experimental in the search box.

Many people would be grateful and the PR starter or others could submit following fixes that @bpasero mentioned truthfully, although in bad spirit, as can be seen by reactions on his comment. It surely is gatekeeping

[EvansMatthew97]

My use case is the following: I like using a monospace font for the workbench. The only way I know of to achieve this is using an extension like subframe7536.custom-ui-style. There is legitimate reason to be concerned about extensions which modify source files and change checksums to suppress integrity warnings - I don't think it's enough reason to push through this PR, but it is something worth considering.

I understand why we are discussing font size adjustments, etc. The VSCode team doesn't want a hacky mess of a feature, and there will undoubtedly be unexpected side effects of just enabling this without second thought. There are many fonts, and there will be complaints about each one that doesn't work perfectly.

I like the idea to make this experimental or a hidden setting. If we're worried about many users dealing with broken workbenches because of the font family/size, let power users set it in their settings.json and use that as an opportunity to gather feedback on where things do and don't work out.

I've personally had a very good experience with JetBrains Mono as my workbench font for the last 3-4 years. Maybe another mono font doesn't work - that's good feedback. Later, as an interim solution, provide a list of recommended fonts that do work well, and let the user choose their own if they really want to.

The same could be applied to font sizes. It might turn out that users don't want the UI to scale with font size, and instead want a scaling option. An experimental feature gives time to figure out what does and doesn't work while making this a lot easier and safer for power users.

An alternative is to allow extensions to modify workbench properties without modifying source files, which doesn't sound easy.

[dzp0839]

I didn't specifically feel uncomfortable with the font size or font of the sidebar when using other tools, until I started using vscode as my main development tool. In contrast, limiting the font size to 13px was foolish. Damn it, this is truly a torment