Further to this, it seems weird that if I want larger fonts _outside_ of the editor I have to zoom in each time I restart.

pls see #291 for the zooming issue (in general pls do not create combo issues :smile: )

+1

v1.4.0 seemed to make the file explorer fonts larger/bolder, making it harder to traverse a large directory

+1

+1

👍

👍

Does the new UI theming interface give access to the font size?

In addition, I would like to increase the line spacing in the explorer. File names are way too close to each other and is fatiguing to look at.

Ha, I was gonna suggest exposing line height so I could decrease it and pack more files into each screen.

just to add another reason:

• changing the Explorer to a monospaced font is easier to read when scanning for files

+1

Please add support for changing font size of EXPLORER window.

Sort of hacky solution for those who interested: increase main font size and set window zoom level to a negative value (cmd + - or window.zoomLevel setting). It's also possible to use fractional values like "window.zoomLevel": -0.75.

@kompot - your approach works perfectly! Here's my user settings file:

{
"workbench.colorTheme": "One Dark Pro",
"editor.fontSize": 12,
"window.title": "${activeEditorMedium} www.BKD.io",
"newFile.defaultBaseFileName": "newFile",
"newFile.relativeTo": "file",
"newFile.defaultFileExtension": ".ts",
"newFile.rootDirectory": "~",
"newFile.showPathRelativeTo": "root",
"newFile.expandBraces": false,
"editor.tabSize": 2,
"editor.formatOnSave": true,
"prettier.semi": false,
"window.zoomLevel": 1,
"git.enableSmartCommit": true,
"terminal.integrated.fontSize": 16,
"terminal.external.osxExec": "Hyper.app",
"atomKeymap.promptV3Features": true,
"editor.multiCursorModifier": "ctrlCmd",
"editor.formatOnPaste": true,
"files.exclude": {
"/.git": true,
"/.svn": true,
"/.hg": true,
"/CVS": true,
"/.DS_Store": true,
"/.history": true,
"/.github": true,
"/.vscode": true,
"**/node_modules": true
}
}

In particular, I feel there is too much space between 2 items on the list, so not enough items fit on the screen. I just compared to the file tree of Eclipse, and it get 48 items in the space where visual studio get 36.

I feel that the sidebar in particular needs to be able to customised wrt: lineHeight, fileFontColor, dirFontColor, and activeLineColor.

Comparing Sublime 3:

to VS Code:

I get fatigued looking at the VS Code tree, and am often unable to find files easily without having to either look away and reset my eyes, or collapsing all the open folders and then starting again from the root to find what I'm looking for. I can't say I've ever experienced that in Sublime, and I think it is the color differentiation of files and folders that prevents it.

When changing the font in the editor.fontFamily, this is not reflected in the rest of the UI, creating a discrepancy between the editor and the UI. Also, there are no workbench.fontFamily or workbench.fontSize settings to compensate for this problem.

For me, setting a small zoom CMD/CTRL+- a couple of times, and increasing the edit.fontSize and terminal.intergrated.fontSize, I'm good to go. It's not as hacky as I thought it would be. Everything is still relative, so using the CMD/CTRL++ changes the whole workspace, which is what I want.

...adding to the various reasons: If I set "workbench.fontAliasing": "none", - given that I am using a non antialiased font in the editor, the explorer (left side of the pic) looks really bad :/

+1
Need to change _fontStyle_, _fontSize_ in Explorer and tab

+1 from me for UI themes like Atom.

I really like this feature in other code editors (Pycharm). Please include the same in your near roadmap.

Equally, it would be great if it was also possible to change the font family.

+1 font customization for explorer too

+1

Need a general UI font family and UI font size settings...

What I would really like to know is why all those downvotes for this feature? What's the downside of being able to change the workbench font?

@picosam The downvotes are not for the idea itself, but for comments stating nothing but "+1" or only containing other ways of expressing agreement/support. These comments are sent as email notifications to everyone, while contributing nothing of significant enough value to warrant such a notification. Showing support for the idea is better expressed by upvoting the original comment or any comments further clarifying the issue.

more than 1 year and we still have to wait this feature :(

Just wondering if there is an ETA on this feature? It would be very handy if we could configure this in the settings json. The current font size makes it very difficult to navigate files in a project. Thanks

I agree that the interface font size is huge, but at least we have @kompot 's hack, which is enough for now.

If I could choose statusBar.zoomLevel separately, that would be a big lift, if for some reason layout integrity would be hard to maintain with free font-sizing.

Pls add some functionality to change the sidebar font. Because of this I'm using alternative editors.

+1

I spent the whole day making the switch from sublime to VSCode. I like everything, except the sidebar, which is kinda weirdly too small. Please expose settings to change line-height, font-family and font-size.

+1

I am transitioning to VS Code from Sublime and the sidebar is the main thing I have an issue with. It would be awesome to be able to customise the line-height and font-size.

I transition from IntelliJ and my experience with VSCode so far is superb.. except for the SideBar. I can't get used to it. A sideBar.lineHeigth option would help a lot with this. A sideBar.dirBackground and a sideBar.dirExpandedBackground option would be nice too, I guess.

+1

+1

+1

Unsubscibe me

On Tue, 20 Mar 2018 13:40 farahabdi, notifications@github.com wrote:

+1

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/519#issuecomment-374600867,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AjugnBFb7O9WsyW3BMQT8i1TaTdkOdVtks5tgQbbgaJpZM4GoAlw
.

Guys, are you even serious? Why the hell are you keep posting your plus-ones, just use a buttons on a starting message.

@steve6274 Do it yourself, there is a button for this, it's in the right bottom corner on this screenshot: https://monosnap.com/file/FJkeWTsHWIhI6DtRXZKXLo0oUHjv43.png

I've switched mostly from Sublime to VS Code and similarly I find the sidebar one of the biggest challenges, for me especially because of lack of differentiation e.g. between folders and files -- icons or not.

I found one of my desires from Sublime in this issue: https://github.com/Microsoft/vscode/issues/10748#issuecomment-241287964 -- a simple request to add bold folders, with the linked comment a possible suggested solution open to feedback.

This (optional config) was rejected because apparently a bold font option needs a whole UX team decision (???) and is "not on the roadmap for the next 6-12 months". I really like VS Code so far, but I find this kind of attitude to be disheartening. It's an optional bold font folder name preference. I remain hopeful though, and I'd be happy to help with such things if need be.

Perhaps this https://github.com/Microsoft/vscode/issues/26128 is actually the one to watch? I missed it when I was reading through before.

Any chance we might see this being implemented before the end of this year?

VSCode Version: 1.21.1
OS Version: Windows 7

I would like see an option to increase the tiny font size used in VSCode menus

Perhaps you expect such a setting be OS-level settable, I feel there is a need for it inside VScode just like there is an editor and terminal font size options there should be the obvious "menu.fontsize" : 14,

I am aware of
"window.zoomLevel": 0.4

But it does not seem to affect the menu and pull-downs.
Thank you.

I would like the option to color certain code folders with a background color
Point to a folder, R-click change background/highlight color

• Regarding font-size, why not support Ctrl-Wheelmouse in each major areas of VSCode and let users set their level of comfort dynamically.
• The Natural way is to Point with the mouse to the Menu, Tabs, Side Tool bar, Panels, Terminal, etc and use the Ctrl-Wheelmouse to set the font-size (zoom-level)
• It is wrong to assume all users want necessarily a global zoom-level or font-size.
  Thank you.

+1.
zoom-level not my favorate

Visual Studio's reply on option to change Comments font: _" As of now, changing the font family is not available. However, this feature request is currently open on the VS Code GitHub repo. We consider you might want to vote for it here: http://msft.social/jeezBz . "_

I fixed this with some custom css.

1. Download be5invis/vscode-custom-css
2. Enable it and add your custom css

I wanted more space for each row in the treeview. I use this styling:

.monaco-tree .monaco-tree-rows>.monaco-tree-row {
  min-height: 25px;
}

Hacky, I know. But it works

@lindesvard Thank you, I didn't know about this extension.

@mchampanis I also got fatigued looking at the explorer. Here is my CSS i added using the be5invis/vscode-custom-css extension. It makes looking at the explorer a far nicer experience.

.monaco-tree-row.has-children {
font-weight: 500;
margin: 8px;
color: #eee;
font-size: 14px;
}

.monaco-tree-row {
font-weight: 300;
margin: 5px;
font-size: 12px;
color: #bbb;
}

When I use VS Code in a virtual machine on my MacBook Pro with a Retina display, I have really terrible font rendering. Everything is very blurry. If I use anywhere near the native screen resolution (2880 x 1800) to try to ameliorate this, the fonts become extremely tiny. I can adjust the font size in the editor and terminal to get passable results, but using the window.zoomlevel option to get the UI to a legible size just makes everything blurry again, since obviously it is just zooming in.

I really wish the option to change the font size were present. As it is VS Code is unusable for me in a vm environment.

@lindesvard Just curious... before I get crazy with this, Will this extension allow me to alter the font type I use for the comments in my code? Just wondering about the limitations. THANK YOU !!

_I realized after I posted this_ that currently there is no way to modify comment fonts. However the other hack by @mchampanis did help neaten up the editor a bit. Hope the option to add fancy fonts to comments is put back in soon.

Yes, I'd like folders to be slightly larger text than files, and rootfolders (the top-level folders added to a project) to have a bit of padding before them, or even a faint top border, so you can easily see where each new filesystem tree begins.

The custom-css extension does seem a bit too much of a hack, though :-)

I managed to changed the font-familyof the tree view and other side bars in my Debian by editing workbench.main.css in /usr/share/code/resources/app/out/vs/workbench/ folder

find .monaco-shell class and change the font-family there.

UPDATED :

Just add .monaco-shell {font-family: "your font";} in the last line of /usr/share/code/resources/app/out/vs/workbench/workbench.main.css file. And u r good to go

@MaxySpark Thanks for the fix. Still, I really wish they would add this feature. I'm sure next time VScode updates this temp. fix will be overwritten and I'll have to change the font-family again.

@MaxySpark while that does change the font, it also gives a corruption error from a fresh install of vscode. Troubleshooting from a fresh install on a separate machine with only this change being made gives me this error every time I open the editor:

@chaddanna just click the gear icon and select Don't Show Again

It's quite mind boggling with all that effort going into VSCode a basic issue like this is still not solved. On OS X the UI font is way too big and the only way to scale it down (window.zoomLevel) results in ugly scrolling wobble. This is a significant usability problem.

Is this still being looked into? When using
"window.zoomLevel": -1,

It makes my font look incredibly ugly

it's been 3 years from the original request, why I keep thinking this has been the most abandoned feature enhancement of them all?

Typical Microsoft fashion.

Typical Microsoft fashion.

Okay, now that just sounds ungrateful. There are many people putting a lot of effort in VSCode (and many of them in their spare time). And definitely unlike "Typical Microsoft fashion" it is open source so nobody prevents you from from implementing this and submitting a pull request.

There must be an issue with upstream Electron which is preventing the implementation of this feature request. Otherwise, I'm sure the VS Code team would have solved it by now. @ramya-rao-a would you chime in please?

Yea, should be a simple edit. I was just checking out this editor and need to at least have a bigger font.

Atom is nice and you can configure everything, so may be a better fit. https://atom.io/

+1

Dear community

We are still not tackling this because we have a lot of hard coded list and tree heights (e.g explorer) in our workbench and making the font size customizable would break the rendering.
This is not a simple fix and requires more elaborate work, currently it is not on our plan to tackle this but we will consider it in the future.

Thanks
isidor

It is totally understandable 🙂. How about just letting us change the font family now? Monospace fonts look great on sidebar.

@swashata That would probably need changing the height of the list/tree heights (not all fonts have the same glyph sizes/heights). I imagine ability to customize fonts would be bundled together with the ability to change font sizes.

In the meantime, the workaround from https://github.com/Microsoft/vscode/issues/519#issuecomment-387148025 (using https://github.com/be5invis/vscode-custom-css), is serving me well.

PS: I'm not on the VSCode team.

@pradyunsg I do know about that. Just not a big fan because I use vscode insider and it updates every day. What I do instead is, just open the devTool and change the font family to Dank Mono.

It would be great to modify sidebar font.

Looking forward to this feature.

Another interesting prospect of this problem is that VSCode already has the ability to switch between different platform-specific UI fonts by default. For example, on Linux, if you install the Segoe UI font from Windows, VSCode will automatically switch from the default Linux font (Noto Sans?) to Segoe UI. Given that this feature is already present, would it be possible to allow switching between said UI fonts, given that they are installed by the user, as the hard-coded spacings are being worked on? This would be still a (rather niche) stopgap but should at least allow for a bit more customizability than what is currently present.

Can we simply implement:

{
  "explorer.fontSize" : 13.5
}

?

Then we can resolve this issue.

Microsoft... this is a basic request. No one's requesting a search functionality that also calls your mom, wishes her a happy birthday, orders her a present on Amazon for same-day delivery (catered to her tastes, of course), and schedules a video call, all while doing your job for you. We're talking basic font changes here.

While the default sidebar font may be fine for certain scenarios, it is absolutely not OK for many developers. Either this needs to be remedied by giving us the options to set:

• the font name
• the font size, and
• the line height

OR make it so editing the main CSS using something like vscode-custom-css doesn't break the app. Heck, a single custom CSS file that is stored in user settings would be alright too.

The problem with custom CSS, though, is sometimes it breaks the layout - you can't scroll down all the way in a sidebar, it mucks up other fonts, etc. And that's why I want to see a native implementation instead of using a hacky system via a plugin that explicitly states that it makes VSCode think it's broken.

It can't be this hard to add a simple feature like this that was requested THREE YEARS AGO.

@dougc84 while I am totally with you, having this feature is not that simple as @isidorn already mentioned, primarily because of the hard coded values related with the explorer. These values are the reason you are not able to scroll down all the way in the explorer since the height of the rows is greater than what is expected, I believe.

Yet, I am frustrated with having to deal with all these downsides, corrupted installation messages, etc. too. I think that this feature request should be taken more seriously because for me VSCode feels really unusable on my 13.3" laptop with the standard font size and I don't want to waste precious space by zooming in the whole app.

So now i cannot change my sidebar font too :(

@isidorn

We are still not tackling this because we have a lot of hard coded list and tree heights (e.g explorer) in our workbench and making the font size customizable would break the rendering.

Why are there hardcoded size values at all?

This is not a simple fix and requires more elaborate work,

I'm so sick of listening to trillion-dollar global corporations whine about how difficult it is to do simple things. Microsoft doesn't have junior devs anymore?

currently it is not on our plan to tackle this but we will consider it in the future.

Currently, it is not in my plans to use VSCode until it offers the simple, simple feature of being able to read my goddamned file tree. Not sure if I'll bother to consider it in the future.

Guys, I know it's annoying, but while @isidorn and the team can't fix it, at least try @kompot 's hack

Indeed, there is a hack. But consider the consequences of the hack: I have to take ownership of files contained within a system directory just to change the font? To me that is absolutely not worth the security risk. Most importantly, this is a basic feature that should not require a hack.

@Al2Me6, no, you don't. The config I'm using on my settings.json:

  "editor.fontSize": 13,
  "window.zoomLevel": -1,

Some of my coworkers are using "editor.fontSize": 14.

@robsonsobral how to change ugly font of sidebar?

@Al2Me6, no, you don't. The config I'm using on my settings.json:

  "editor.fontSize": 13,
  "window.zoomLevel": -1,

Some of my coworkers are using "editor.fontSize": 14.

Yeah, that does change the font size, but as a side effect you get this annoying trembling during scrolling (https://github.com/Microsoft/vscode/issues/28439). There really is no good solution right now for adjusting UI size. I understand hardcoded values for prototyping, but having production software shipping with such annoying usability issue is a bit mind boggling, especially given how much effort Microsoft is putting into VSCode.

@shirshak55 , if you're talking about the typeface, I don't know. But if you're talking about a possible bad rendering, try different zoom values.

@knopp , I never notice that, but I'm using Windows right now. I gonna check it on Mac, next Monday.

Guys, the topic is font size and font face. Scaling and zoom levels don't address the issue. If it works for you, great. But scaling and zoom is not the issue - it's the ugly, compressed font that results in a hard-to-read file and folder view.

@isidorn

We are still not tackling this because we have a lot of hard coded list and tree heights (e.g explorer) in our workbench and making the font size customizable would break the rendering.
This is not a simple fix and requires more elaborate work, currently it is not on our plan to tackle this but we will consider it in the future.

I'm sorry, but this is an unacceptable response. This is an electron app at its core. You're dealing with (in the most basic sense) basic web technology on the front end. This is a problem many other developers have solved without hardcoding monaco classes (or, even worse, manually entering style values - come on, it's 2018) all over the place. As a Microsoft product, I can't say I expect better (UI is not, and has never been, Microsoft's forte), but if you're going to have a product like this available for multiple platforms, multiple languages, and multiple uses, let the users tweak the CSS for their needs. The "break the rendering" problem... well... isn't a problem when using custom CSS, save for a few issues with not being able to scroll all the way down, but can easily be fixed with a simple overflow: scroll attribute. And saying the installation is corrupted by custom CSS with a plugin that is allowed in the extensions marketplace is completely nonsensical.

I could not agree with @dougc84 more.

In my mind this really reeks of corpensource horseshit.

Microsoft wants the name and the fame, but as soon as they get mass adoption (or close to it), they start focusing on features that only benefit the benefactor.

I'm literally starting to wonder if there's some sort of ridiculous milieu control behind the resistance to this feature request.

Honestly, how many hardcoded values could there possibly be? 9 trillion? Each one unique?

Attention all badasses currently sounding off in the comments here, if the fix for this is so "simple" "junior devs" could do it because it's just "basic web technology" what exactly is stopping _you_ from opening a pull request that fixes the problem?

It was easier to complain about this stuff when all MS stuff was closed source, but they've made one of the best editors/IDE as a free, open source project. Don't like it? Go use Atom. Or one of the many other text editors. If VSCode is such horseshit why are you even bothering?

To be clear, I also want this issue to happen, that's how I got here. But I am tired of the pointless derision of the maintainers when it's both free and open source! This thread should probably be locked...

@austinbutler

Attention all badasses ...

As much as I appreciate the compliment, since when is basic CSS "badass"?

what exactly is stopping _you_ from opening a pull request that fixes the problem?

The fact that I'm not in the habit of donating my time or skills to Microsoft marketing initiatives.

Microsoft wants to use VS Code as a vessel to capture the hearts and minds of developers. They want it to be the first stop for your code along a pipeline that I imagine they envision includes Github, and then Azure.

Since when is Microsoft a charity that needs help from the community to achieve its goals? Are they short on money? Should we setup a Kickstarter page for them?

It's not my job to fix Microsoft's technical debt. I'm not the one that hardcoded all the values into it in the first place. You broke it, you fix it.

It was easier to complain about this stuff when all MS stuff was closed source, but they've made one of the best editors/IDE as a free, open source project.

You can hardly call VS Code "one of the best editors" given that the entire point of this (THREE YEAR OLD) thread is that VS Code is missing one of the most basic, fundamental features of an IDE and thus is rendered useless for 40-50% of its target market.

How is this software "one of the best" when over half of the intended users can't use it because a trillion-dollar tech giant is being brought to its knees by a CSS bug?

Don't like it? Go use Atom.

Ummm ... have you been reading the news lately?

If VSCode is such horseshit why are you even bothering?

VS Code itself is not horseshit, the way that Microsoft is prioritizing features that benefit their business plan over features that benefit the actual users, is.

To be clear, I also want this issue to happen, that's how I got here.

Good, then maybe you can understand that this feature request is THREE YEARS OLD. How long is a user base expected to wait? How long does Microsoft think they have before some other corpensource IDE comes along and offers the magical ability to customize the font in its file tree?

But I am tired of the pointless derision of the maintainers when it's both free and open source!

The pricing model Microsoft chooses for their software is not my problem. If it was a paid product and offered the features I need at a reasonable price then I'd be happy to shell out the $100 or so just like I have in the past for many, many other titles.

If Microsoft wants to use VS Code as advertising to connect with the dev community fine. But if they can't handle a CSS bug then maybe it's time we start looking for a new corporate benefactor.

This thread should probably be locked...

That's an excellent idea. Everyone knows the best way to improve your software is to ignore your users and silence them when they criticize you.

Even better: why don't we just ban anyone that dares criticize Microsoft from Github altogether?

Alright guys, chill out.

The reason _many_ people don't contribute is not due to their ability to write the feature. Many of us don't have time to do our jobs AND spend time on learning an entirely new app, framework, style guides, and (in some cases) languages to make it happen. And, with 169 current pull requests, as well as a defined roadmap, the problem isn't that MS/the VSCode team _can't_ make it happen, they simply aren't making it a priority (and it's not even on their radar).

The reason this issue exists and is getting traction is due to a feature that people desire. But negative attention isn't getting us anywhere.

@austinbutler is right - someone needs to step up and contribute, despite the unnecessarily harsh words. I personally don't have the resources to contribute to this project. If it was ruby (which, I know, doesn't really work with desktop apps), I'd try to carve out some time to make something happen, but it isn't. It's electron, and I'm just not familiar enough with server-side JS _or_ node.js _or_ the framework.

That said, @AJB99 is also right (also, again, despite the unnecessarily harsh words). MS isn't listening to their community, and they aren't bothering to address the issue. MS is working their way into open source platforms - VSCode as the first big one - but they are a corporation at heart with their own goals and roadmap, one that will inevitably push people away. And, as I mentioned before, MS has _never_ been UI centric. Windows has always been the ugly OS. The ribbon bar, for example, in most of their apps just isn't intuitive or easy to use. Windows 10 feels like I'm using KDE from 2010. That said, MS released VSCode as a simple editor, so people are looking to it as an alternative to Notepad++, Sublime, Atom, Komodo, JetBrains, etc., _not_ a full-fledged IDE, like Visual Studio. Most people interested just want proper code highlighting and indentation, some basic auto-completion, some nice colors and a pretty UI, and possibly some simple tool integration. If they want more, there is always Visual Studio or one of the myriad of powerful IDEs out there. Some of those basic requirements are simply missing.

Either way, there's no reason to be heated over it. Comments and upvotes on issues tell the dev team we're interested or want something. However, responses from them saying "we aren't considering it" while leaving the issue open, or not addressing it at all, just tells users, like myself, that they don't care. That's the problem.

This is disgusting: https://video.twimg.com/amplify_video/1049514660783943680/pl/5aBOHl_qGaB35UXH.m3u8?tag=8

New guy on the thread, but just read through all of it and holy crap the negativity here....Where did this sense of entitlement come from? It's a FREE, Open Source product. I don't care if the owner is some random developer, "our lord and savior" Google or the "devil incarnate" Microsoft, I won't ever understand this kind of attitude towards FOSS products. It's toxic and completely unproductive.

I'm desperate for this feature as much as everyone else here, but quite frankly, if I was the maintainer of this, I'd be even less inclined to build the feature with all the entitled demanding going on...

@sgarcia-dev I have finally seen a bit of common sense here, thank you.

It's toxic and completely unproductive.

Well being patient, being nice and being polite has being working so well for us so far. I guess we should just continue begging.

I am tired now :) Switched to sublime back and found it is better. And sidebar looks awesome now :D .

@panoply

Well being patient, being nice and being polite has being working so well for us so far. I guess we should just continue begging.

Well, being an entitled asshole who just whines isn't working so well either.

I'm free after 11.11, maybe I can have a try.
But who can let me know what you want ？
Just font size of side window ?

@saighost

Font Family

Font size

line-height too...

Many layout in code direct use 22px, lot of work to do.
maybe I can push a version, that font size can be set but not more than 22px.
And then I will try to make layout can adapt more font sizes.

Time to make some noize on this PR that would solve this issue https://github.com/Microsoft/vscode/pull/63602

Hello, I see that this is a subject that fascinates a lot of people.

I opened an issue today(#66472) without knowing that it existed.

I have not put all the thread of conversation (because it dates from 2015), but I think that the bottom of the problem comes mostly from Electron.

For example, under linux, discord does not render fonts correctly. This is also the case in other Electron-based applications, but I will not wrap an exausthive list.

I looked at the PR and the most interesting thing that comes out is the change of do not default according to the OS.

I keep the subject in the eye to see if there are any changes

The bottom of the problem does not come from Electron, it comes from devs that do not care about UI customization. The Electron itself does not really restrict you from setting a font, look how easy it's done in Atom, and in realtime!

The issue is 4 years old, by now we can clearly see how high the priority is.

yea if atom doesn't have such problem then code should not have too. I wonder when atom xray release and i can leave code safely and happily :(

https://github.com/Microsoft/vscode/pull/63602

I am not convinced. Electron should provide basic correct rendering of fonts according to the OS where it works.

I am not convinced. Electron should provide basic correct rendering of fonts according to the OS where it works.

Electron will render whatever font and size the stylesheet specifies. Blaming electron for hardcoded font/font sizes/line heights is pointless.

The ability to change the font weight in the sidebar would help a lot too.

For those of you having issues with this still. Until they can work around it here is a quick fix. Download the Custom CSS and JS extension from here: https://github.com/be5invis/vscode-custom-css and in a custom css file just edit the .explorer-viewlet property. An example

.explorer-viewlet { font-family: "Space Mono"; font-weight: bold; }

The resulting view is this

@dr3amnightmare the key point here is not that there is no way (hacky or not) to accomplish the intended effect, it's that it is simply unacceptable to use a workaround involving modifying the application's files to accomplish it.

As the original person who started this thread, I am absolutely amazed that this still hasn't been given attention after even more than 3 years.

Microsoft hates programmers.

On Feb 1, 2019, at 11:07 PM, hsdk123 notifications@github.com wrote:

As the original person who started this thread, I am absolutely amazed that this still hasn't been given attention after even more than 3 years.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/519#issuecomment-459933345, or mute the thread https://github.com/notifications/unsubscribe-auth/AGfxtGLeUg1NPizuVlNDvel4IPVI-WLFks5vJQ8egaJpZM4GoAlw.

As developers, I am sure a vast amount of us can agree that when setting up any development environment, the look and feel of our work base is absolutely one of the first things we want to get 'just right' - a key factor in order to maximise productivity.

Neglecting this issue, I feel is a big statement into the neglect of this everyday phenomenon that I am sure even the developers of VS Code would be able to relate to.

Any how, this thread has received over 1000+ reactions - I doubt that this is insufficient data in displaying this issue is something fundamental that needs addressing. If even with this much data this still is not addressed, it seems that the only logical conclusion one can make is that this is just being purposely ignored or pushed.

If development is truly data driven, this should have been an issue addressed a long time ago. This thus just seems like another sad example of important issues being sent down the drain due to near-sighted product managers or development cycles that favour easy to get, flashy updates than prioritisation of the issues that are truly important, but may take decent time and contemplation.

More than 3 years have passed. If this issue was given even the smallest bit of attention, I doubt that nothing would have been alleviated during this span of time. If anyone were to propose a counter argument that attention had been given, then that would seem to be a big statement into the capability of those developing.

Get this one issue fixed and VSCode will have more than 1000+ supporters for that particular update. Is that still not enough incentive?

@Al2Me6 While I agree wholeheartedly that this is an issue that should have been addressed and fixed 3 years ago when it was reported, it seems people still manage to find their way to this thread 3 years later to be let down by the developers. I arrived on that issue today and decided to hack a fix for myself and just wanted to share an alternative for those who come in the next 3 years while this issue is neglected so they can at least have some way to go about fixing it. Especially those who are HTML/CSS and/or JS deficient (I know I am lacking pretty hard on that front). Should I have time in the next bit, I'm going to consider taking a look at the code and finding a way to add this as an option and submit a pull request for you wonderful few who have been slighted. No promises though. But I will try!

@dr3amnightmare there is already a pull request but nobody gives a damn. But I don't see any progress from Microsoft teams.

63602

@knopp
2018-Aug-17
"... it is open source so nobody prevents you from from implementing this and submitting a pull request."

It has been over three years and this hasn't been implemented. If the change were possible [through community contribution], it would have been done by now.

@panoply
2018-Nov-06
"This is a multi-billion dollar company ..."

You have a huge and pervasive company like MS that often garners a lot of hate, often deservedly, IMHO. Depending on whose data you read, MS still holds the largest share of business OS installation.

@isidorn
2018-Aug-21
"... we have a lot of hard coded list and tree heights ..."

@hawkgs
2018-Oct-23
"... this feature is not that simple as @isidorn already mentioned, primarily because of the hard coded values ..."

This is disconcerting. These are the people with whom you implicitly entrust with your most private data as you browse the web and engage in online financial transactions. (Oh, and your company's payroll and HR systems are most likely sitting on Windows servers.) And yet these are the same people who can't update an editor because of hard coded features. Perhaps a CS101 refresher would be apropos.

I find it rather hilarious that the VSC designers developed a code editor with a proportional font ... which just happens to be one of the hard-coded features!

I have no love for MS, Apple, Google ... any of the lot. I certainly have no commitment to VSC. This "explorer font" issue was the last straw for me. My solution: back to Vi. (I can type much faster than I can "type and mouse about.")

Remember, you only need two characters for the year!

Please MS, lock this thread! @isidorn, @egamma?

I am interested in following progress on this issue, not in vapid complaining or posturing from hardcore badass devs. Yes, _obviously_ this is something many people want. Yes, if MS found it to be important they'd have done it after three years. Do you think it's just a certain threshold of insults that will motivate MS to implement this? And we're just seeing what that threshold is? Something tells me that's not what's going to help.

This is a free, open-source product. If you think MS is garbage and VSC sucks, go ahead and use VIM, VI, Nano, Atom, Sublime, whatever it is that's vastly superior, and please stop posting hateful garbage here. If you're a reasonable person who thinks, "Ya know, VSC is pretty good, but I wish it allowed changing the font-size and font" then +1 the original post here, subscribe, and move on...

Please MS, lock this thread! @isidorn, @egamma?

If you're a reasonable person who thinks, "Ya know, VSC is pretty good, but I wish it allowed changing the font-size and font" then +1 the original post here, subscribe, and move on...

Unfortunately, discussion locking locks reactions for the original post. And it can break users-opinion-based issues sorting.

This article has allowed me to understand many things: https://pandasauce.org/post/linux-fonts/

This has nothing to do with the problem here; the issue concerns hard-coded fonts and font sizes, not rendering problems.

That's part of the problem. On MacOS / Windows the overall rendering of vscode fonts is correct. Unlike linux.

On any other OS than linux, want to change these fonts, it's a little gadget.

The part of developer wishing to change the appearance of vs under macos / windows is infinitesimal

No.

I’m on macOS. The fonts are fine as far as actual font rendering, but the
choice of font is very difficult to read, not to mention the narrow letter
spacing and line heights.

It has nothing to do with Linux or Mac or Windows. It has to do with user
preference. If I’m going to stare at an app for 40+ hours a week, I don’t
want to struggle or hack to make things legible.

On February 7, 2019 at 2:36:27 AM, Benjamin Nolmans (
[email protected]) wrote:

That's part of the problem. On MacOS / Windows the overall rendering of
vscode fonts is correct. Unlike linux.

On any other OS than linux, want to change these fonts, it's a little
gadget.

The part of developer wishing to change the appearance of vs under macos /
windows is infinitesimal

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/519#issuecomment-461315687,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtcPbv2i859LySEmBMCaL6O2oifAWuPks5vK9d7gaJpZM4GoAlw
.

Am I the only one that thinks this is starting to feel like an episode of "The Expanse"?

@austinbutler Such a penchant for quashing the vox populi. Surprising.

I am interested in following progress on this issue, not in vapid complaining or posturing from hardcore badass devs.

Dude, again, it's CSS. There is nothing "hardcore" or "badass" about it.
(Except that those that are truly masters of CSS are basically gods in my mind.)

Yes, _obviously_ this is something many people want.

Correct.

Yes, if MS found it to be important they'd have done it after three years.

I'm with you so far ...

Do you think it's just a certain threshold of insults that will motivate MS to implement this?

Maybe?

And we're just seeing what that threshold is?

Also maybe. Also fun.

Something tells me that's not what's going to help.

At this point, it can't hurt. Something, something, fuck Microsoft.

This is a free, open-source product.

No, it's not. You pay with your soul.

This is a corpensource marketing initiative by a global technology behemoth. This is a ploy designed to capture your hearts and minds (albeit a damn fine one). But in typical Microsoft fashion, they're fucking up the UX they need to capture your heart, or your mind.

VS Code is not some altruistic offering from the tech god MS. If they could put a $100,000 price-point on it, they would.

The Great and Evil Microsoft has proven over the entirety of it's 43 year existence that it will stop at nothing to dominate the software landscape in any way it can.

Its leaders will lie, cheat, and steal to gain any point of leverage that enables them to foist their shitty, ugly, buggy, insecure software upon an unsuspecting planet.

So why do you think they've suddenly got FOSS-fever and they're just oh-so-jazzed to be able to offer this great gift to the programming community?

(Unless, of course, if you want to change the font in your file-tree. In which case you can direct your request to [email protected]).

If you think MS is garbage

Following ...

and VSC sucks

Incorrect. VS Code is a fine piece of software. Just lacking a few critical features.

This thread hasn't been about a feature request for years. This is about why Microsoft is refusing to implement this feature request.

It doesn't make any sense. Why not merge @saighost PR? I haven't run a test build myself, but from what I saw it's inline style removals, some class additions, and some config var additions (and it looked clean and consistent). Surely MS has an intern or someone they can say: "Hey, can you run a build and the tests on this @saighost PR for #519?"

They don't want to fulfil this feature request.

And now I really, really, really, really want to know why.

@dougc84

You have to differentiate between rendering and style.

Here everything is only about style. No rendering.

I spend a lot of time in vscode because he is for me the editor to do everything.

However, there is only under linux that I want to change the font because the default rendering is not clean.

The article I give is very interesting because even if you change the font, if the rendering is not good, it gives you an answer to this problem.

This is not a "Linux" problem. On Ubuntu (Xubuntu), font rendering for VS Code has always been 100% perfect. I'm subscribed to this bug because I'd like just to make some of the fonts bigger. This is probably a problem in your distribution.

@Xarkam so why do atom don't have rendering issue? vs code and atom both are based on electron..

@Xarkam Maybe for your particular distro and build that's an issue. If it is, that is a separate issue, and you should submit a new issue for that (have you tried adjusting your zoom level, because that can mess up things?). For me, and for most people here, it's legibility (not style). Zoom is not a solution, as it makes EVERYTHING larger or smaller. I don't want everything larger. The editors are fine. I just want to be able to see all the files listed with appropriate spacing to not misclick when looking through files, being able to differentiate between a lowercase L and a capital i without squinting, and being able to read filenames easily. That is solved with a simple font change (likely to a fixed width serif font) with better letter spacing, and being able to adjust the padding in the file view. That's it. It's not hard to understand that your problem is different than everyone else's here.

One of the most upvoted and commented issue and Microsoft doesn't care?
How hard is to add option to change interface font, it most basic option and other IDEs have it.
My preference is to have same font in the interface as in the editor, having different font styles in the editor and in the sidebar bothers me.

@wooque hmm I don't think microsoft will think about it because they didn't cared even after PR was made on #63602 making author effort useless. Those upvotes means just a number to microsoft :)"
Its already 4 month PR arrived and noone cared from microsoft side :(
I wonder when atom xray comes :(

For those of you having issues with this still. Until they can work around it here is a quick fix. Download the Custom CSS and JS extension from here: https://github.com/be5invis/vscode-custom-css and in a custom css file just edit the .explorer-viewlet property. An example

.explorer-viewlet { font-family: "Space Mono"; font-weight: bold; }

This just changes the font of the explorer viewlet. I found the following rule changes the entire UI font on Mac:

.monaco-shell.mac,.monaco-shell.mac .monaco-menu-container .monaco-menu { font-family: "YOUR FONT HERE"; }

Edit: Looks like in latest VSCode (1.32.1 as of this writing), the CSS for Mac becomes:

.mac{ font-family: "YOUR FONT HERE"; }

I found this by de-minifying /Applications/Visual\ Studio\ Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.css, and then running:

grep apple-system DE-MINIFIED-CSS -A 5 -B 5

And trying plausible looking rules until the whole UI changed.

Probably you need to tweak the paths for your operating system, and those rules look a bit Mac-specific.

A +1 from me for a real solution to this. No feedback from Microsoft on
https://github.com/Microsoft/vscode/pull/63602 is a bit disappointing.

I fixed this with some custom css.

1. Download be5invis/vscode-custom-css
2. Enable it and add your custom css

I wanted more space for each row in the treeview. I use this styling:

.monaco-tree .monaco-tree-rows>.monaco-tree-row {
  min-height: 25px;
}

Hacky, I know. But it works

.monaco-tree-row.has-children {
font-weight: 500;
margin: 8px;
color: #eee;
font-size: 14px;
}

.monaco-tree-row {
font-weight: 300;
margin: 5px;
font-size: 12px;
color: #bbb;
}

Are these supposed to work at this point? The margins between sidebar items are not increasing :(

To change font families and sizes of the workbench, apart from installing plugin vscode-custom-css as referred above, another more direct way has been proofed to be workable (Tested on VS Code 1.32.3):

1. Search the file "workbench.main.css" in your disk, the proper file path might be "C:\Program Files\Microsoft VS Code\resources\app\out\vs\workbenchworkbench.main.css";
2. Make a backup of the file;
3. Open the file and search for ".part>.content", there might be 4 matches, just modify the 1st match per your preference like .part>.content{font-size:14px; font-weight: bold; font-family: Iosevka Term Slab Medium, Consolas, Courier New, monospace;}" ;
4. Save this file and Restart Vs Code, Bingo :)

Is there a way to change the font for code “comments’ ??

rich

On March 15, 2019 at 12:51:48 AM, Mike Zheng ([email protected]) wrote:

To change font families and sizes of the workbench, apart from installing plugin vscode-custom-css as referred above, another more direct way has been proofed to be workable (Tested on VS Code 1.32.3):

Search the file "workbench.main.css" in your disk, the proper file path might be "C:\Program Files\Microsoft VS Code\resources\app\out\vs\workbenchworkbench.main.css";
Make a backup of the file;
Open the file and search for ".part>.content", there might be 4 matches, just modify the 1st match per your preference like .part>.content{font-size:14px; font-weight: bold; font-family: Iosevka Term Slab Medium, Consolas, Courier New, monospace;}" ;
Save this file and Restart Vs Code, Bingo :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

To change font families and sizes of the workbench, apart from installing plugin vscode-custom-css as referred above, another more direct way has been proofed to be workable (Tested on VS Code 1.32.3):

1. Search the file "workbench.main.css" in your disk, the proper file path might be "C:\Program Files\Microsoft VS Code\resources\app\out\vs\workbenchworkbench.main.css";
2. Make a backup of the file;
3. Open the file and search for ".part>.content", there might be 4 matches, just modify the 1st match per your preference like .part>.content{font-size:14px; font-weight: bold; font-family: Iosevka Term Slab Medium, Consolas, Courier New, monospace;}" ;
4. Save this file and Restart Vs Code, Bingo :)

This solves changing font face, but not font size. The line heights are hard-coded. So when you reduce font size you'll just end up with lot of whitespace between lines.

To change font families and sizes of the workbench, apart from installing plugin vscode-custom-css as referred above, another more direct way has been proofed to be workable (Tested on VS Code 1.32.3):

1. Search the file "workbench.main.css" in your disk, the proper file path might be "C:\Program Files\Microsoft VS Code\resources\app\out\vs\workbenchworkbench.main.css";
2. Make a backup of the file;
3. Open the file and search for ".part>.content", there might be 4 matches, just modify the 1st match per your preference like .part>.content{font-size:14px; font-weight: bold; font-family: Iosevka Term Slab Medium, Consolas, Courier New, monospace;}" ;
4. Save this file and Restart Vs Code, Bingo :)

Will probably lose everything on each upgrade. At least that's how it works on Linux.

Sorry to let you think my PR is the full solution.It Just can change sidebar part, not for all of workbench.
I think Custom CSS and JS extension is good idea, maybe plugin is batter solution than patch at this time.
Maybe write a plugin for this, make it easier to use.

+1

+1

Here is a prime example of why this needs to be in the settings - See the menu font. I've already zoomed in the rest of the application, otherwise I wouldn't be able to read it, like the menu! This issue also affects FF and Thunderbird and Chrome and literally every other piece of shit software which doesn't adhere to desktop standards.

Edit: Settings -> Window: Title Bar Style = custom => I can see the menu!!

Those browsers etc work fine in HiDPI in GNOME since they switched to GTK3. Qt still hasn't quite got to grips with HiDPI support, so your problem is probably caused by KDE.

Yes, but not being able to change those fonts aren't KDE's fault.

But the example highlights the tiny menu font. I think the menu isn't part of the HTML/CSS, it's managed by the system UI. GTK3 in GNOME "just works", but things can get complicated when you try to use Qt in GNOME or GTK in KDE. As you can see from Arch's hidpi guide, KDE and Qt are less consistent.

I tried this but it only changes heading fonts. It does not affect any ‘comment’ fonts which is what I was looking to modify. Are there any other options that do work on ‘comments’?

rich

On March 15, 2019 at 10:08:30 AM, Rich ([email protected]) wrote:

Is there a way to change the font for code “comments’ ??

rich

On March 15, 2019 at 12:51:48 AM, Mike Zheng ([email protected]) wrote:

To change font families and sizes of the workbench, apart from installing plugin vscode-custom-css as referred above, another more direct way has been proofed to be workable (Tested on VS Code 1.32.3):

Search the file "workbench.main.css" in your disk, the proper file path might be "C:\Program Files\Microsoft VS Code\resources\app\out\vs\workbenchworkbench.main.css";
Make a backup of the file;
Open the file and search for ".part>.content", there might be 4 matches, just modify the 1st match per your preference like .part>.content{font-size:14px; font-weight: bold; font-family: Iosevka Term Slab Medium, Consolas, Courier New, monospace;}" ;
Save this file and Restart Vs Code, Bingo :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@teresaejunior this will generate

Installation appears to be corrupt [Unsupported]
VS Code does a background check to detect if the installation has been changed on disk and if so, you will see the text '[Unsupported]' in the title bar. This is done since some extensions directly modify (patch) the VS Code product in such a way that is semi-permanent (until the next update) and this can cause hard to reproduce issues. We are not trying to block VS Code patching, but we want to raise awareness that patching VS Code means you are running an unsupported version. Reinstalling VS Code will replace the modified files and silence the warning.

Also for me the path was

C:\Users[name]\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench

Really, we are in 2019 and still is not possible to change font-size of Explorer menu ???

1. Help
2. Toggle Developer Tools
3. Find element, change it's css
4. ???
5. Profit😎

• Help
• Toggle Developer Tools
• Find element, change it's css
• ???
• Profit😎

There are line heights specified in source code.

• Help
• Toggle Developer Tools
• Find element, change it's css
• ???
• Profit😎

Is this possible without creating your own theme?

• Help
• Toggle Developer Tools
• Find element, change it's css
• ???
• Profitsunglasses

There are line heights specified in source code.

I am no expert with CSS, but playing around with Developer tools quite a bit, I was unable to figure out a way to achieve the same layouts that were reported in this issue earlier.. For example this: https://github.com/Microsoft/vscode/issues/519#issuecomment-387007363 doesn't seem to work anymore, the ids are changed and are now much more difficult to make work.. Paddings, margins just make the text disappear and min-height does nothing with .monaco-tree .monaco-tree-rows>.monaco-tree-row or .monaco-tree-row.has-children seem not to be the same anymore and now there seems to be at least 5? different classes which affect how one row is displayed..

1000 thumbs up's for this issue and still nothing? We can almost say "6... years... later..."

Guess I'm kinda fixated on it because I used to use sublime and really like the feature but it would be really nice if MS would add the feature of being able to use fancy fonts for the comments section in our code. Still waiting. Guess it must be an extremely difficult thing I'm asking for. Still a big fan of VS Code tho.

This is Microsoft version of Steve Job's "For some reason we developed a word processor without fonts". But 40 years later. Not even an Apple fan. Just to say.

This issue was created on November 2015 and it's May 2019, there's a pull request submitted on November 2018 and this most basic feature is still not being discussed. It's a shame because vs code has got to be hands down the best editor/IDE I've ever used. Low down dirty shame.

I gave up on @microsoft and VSCode. I switched to Atom. It has its own faults, but at least I can read the damn fonts.

At the bare minimum, It'd be nice if they could at least tell us the technical difficulties involved in getting this working. I'd even be happy with a potential time-scale on when this issue could at least be considered...

I could be wrong, but from some comments, it seems some people are blowing this problem out of proportion. I would like to have this feature to adjust the fonts to my liking too. But if someone can't even read the fonts, zooming in/out will work, even if it may not look that great.

There are some CSS hacks in the previous comments too.

@Jaeiya for the technical difficulties see https://github.com/microsoft/vscode/pull/63602

For any future on-lookers, Custom CSS and JS Loader plugin does work.

// settings.json
"vscode_custom_css.imports": [
  "file:///path/to/file.css"
]

// Aforementioned example files content
.mac, .windows {
  font-family: Desired-Font, FiraCode-Retina, Roboto, monospace;
}
.monaco-workbench, .monaco-workbench .part > .content {
  font-size: 16px;
}

.other-css-selector        { content: "??????"; }
.other-css-selector::after { content: "profit"; }

Note

• Imported file changes to not immediately propagate.
• Use reload custom css/js -> reload window to see the changes

@SidIcarus is there a templete to write for linxu? should it change to

.linux {
  font-family: Desired-Font, FiraCode-Retina, Roboto, monospace;
}

and what's the meaning about "??????"?

So, regarding workbench font size, I really wouldn't be holding my breath. Yesterday I forked VSCode to finally fix overly large workbench fonts on OS X (to bring it on par with XCode), and this is what I had to do simply decrease font size and tree row heights in all views. These things are hardcoded in so many places, it would take significant effort to make it configurable.

It is possible that the commit link above will stop working after rebasing and force pushing, but it should still be within first few commits here.

There's binary release for OS X available here, based on VSCodium. I plan to update it semi-regularly. Or maybe even create a script to periodically rebase it and trigger travis build. The release is not code signed so after downloading you need to right click and choose "Open", if you want to try it.

Original VScode workbench font size:

After the patch:

(There is also another commit that reduces tabs height from 35 to 30 pixels)

Okay, so I made an extension that lets you change UI font sizes, font family, row heights and even override stylesheets from settings.json. It's quite experimental at this point and might not be for the faint of heart.

For this FR, the line height option should also be added
Related: #59873

+1

++

I think there are a lot of folks waiting for this feature..

+1

+1

Does anyone know if there's a GIF meme for Microsoft tripping over their own stupidity and accidentally getting their head stuck up their corporate ass?

+1 Want this feature too

@caioproiete That's not a bad idea at all, but it's a tricky calculation.

What sort of punitive damages windfall can one expect from being subjected to corpensource horseshit these days?

P.S. Don't thumbs-up your own comments. Only assholes do that. ;)

Folks, please don't make noise on this issue? There are people (like myself) subscribed to this issue because we want to hear (if?) when someone from the development team chimes in to provide a status update.

Useful comments like @knopp's -- https://github.com/microsoft/vscode/issues/519#issuecomment-499584551 -- get buried by such noise.

Twitter exists, for your hot-takes/quirky comments and responses to the same. Further, "I want this too" comments aren't helping anyone here either. To show that you want this, please :+1: this issue's description.

@pradyunsg

There are people (like myself) subscribed to this issue because we want to hear (if?) when someone from the development team chimes in to provide a status update.

That is never going to happen.

The only status update you need to hear is: Microsoft killed VS Code in the dumbest fucking way possible.

They don't love you, they never did. They have only ever wanted you to revere them just long enough to take advantage of your energy in order to advance their own goals, and for their profit.

Microsoft disdains programmers.

honestly i think it would be much better if microsoft had told they are not
solving this issue. Switched to vim and never became so much happy. Their
product like internet explorer helped me to switch to firefox now vs code
made me switch to neo vim.

Thanks again microsoft. I love you no matter what.

On Mon, Nov 4, 2019, 3:50 PM AJB99 notifications@github.com wrote:

@pradyunsg https://github.com/pradyunsg

There are people (like myself) subscribed to this issue because we want to
hear (if?) when someone from the development team chimes in to provide a
status update.

That is never going to happen.

They don't love you, they never did. They have only ever wanted you to
revere them just long enough to take advantage of your energy in order
to advance their own goals, and for their profit.

Microsoft disdains programmers.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/519?email_source=notifications&email_token=AB5Y4YMYFJLENVQRIEIKC3TQR7XXRA5CNFSM4BVABFYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC6XETY#issuecomment-549286479,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5Y4YJS4X5EKSM6RCU2GDLQR7XXRANCNFSM4BVABFYA
.

OMG what a kindergarden here. Some commenters need a serious fact-check or even therapy. You basically accuse the dev team of being ignorant, no wait, this must be some evil master plan of MS right from the beginning.

Let me help you with some facts: This team has created vscode in literally no time, has a very open development process and has implemented many many features suggested by the community. Thats very uncommon for a piece of software with this adoption rate. The result is a very capable, platform independent, graphical editor with tons of addons/plugins. And yes there is an agenda, any dev team without an agenda will also never have a product. Geez.

Now you dont get your so much wanted lollipop, and everyone turns into crybabies. Guess what - there are other candy shops, they might sell you your lollipop...

@jerch I count your comment as offensive. You can sort issues of this project by +1. And I think this is should be an agenda of this project, regardless issues with security, bug and same labels.

@AlexWayfer Feel free to see it as you wish. All I did was to mirror how ppl are losing manners. Nagging on a dev team never gonna help, it just makes things worse. Not going to continue the meta discussion.

And I think this is should be an agenda of this project, regardless issues with security, bug and same labels.

So back ontopic: Yes, the idea sounds good (though I dont need it myself). But given the hassles it might introduce for layouting and such and the issue list in its full glory they might have good reasons to not officially addressing it yet. Thus all we can do is keep asking until we get a statement.

so, no answer?

any response ?

any response ?

Yes: https://github.com/microsoft/vscode/issues/519#issuecomment-414583479

@AlexWayfer that was last year.

@AlexWayfer that was last year.

And the author was @isidorn, yes.

Let's write more useless facts!

Do you want this feature? Implement it! Or pay for its implementation.

There is no responsibility by free open source projects. Just use this program or not. I'm not using until this issue done, because I don't want to implement it myself.

yea

Make a good text editor beat everybody out of competition and then ...

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

As a workaround, I customize the window.zoomLevel setting to my liking for the workbench font size and then adjust editor.fontSize to compensate the editor font size. For example:

// In VS Code's settings.json
{
    ...
    "editor.fontSize": 13,
    "window.zoomLevel": -1,
    ...
}

This is a palatable workaround for the size of the workbench font until a better solution is presented. Please stop the bickering and hate on MS; it's not helpful.

@duanehutchins sorry but these hacks create hell lot of problem . Sometime due to such hacks font don't work properly on console and many many issues. Check past replies 👍
https://github.com/microsoft/vscode/issues/84194

"Please stop the bickering and hate on MS; it's not helpful."
What is helpful? Wait for another 10 years? Another Hack that causes editor problem and increase their bug list?

What is helpful?

As I wrote above:

Implement it! Or pay for its implementation.
...
Just use this program or not. I'm not using until this issue done, because I don't want to implement it myself.

I asked this a while back but a lot of changes have occurred to VSC since, so I apologize if it is redundant. It doesn't seem that this feature has been enabled yet but I'll ask again:
Is there a way to change the font for code comments aka fancyfont?

Is there a way to change the font for code comments aka fancyfont?

There is a way to create a separate issue for separate change/feature.

This issue is about font size in UI, not about font family (or even size) in code editor.

@AlexWayfer its both font size and font family.

Allow to change the font size and font of the workbench

@AlexWayfer its both font size and font family.

Allow to change the font size and _font_ of the workbench

OK, thank you, sorry.

Anyway, it's about workbench, not code comments (in code editor).

this feature is very requested !!!!! we need it ASAP !!

I wonder if I can make a global font setting, including sidebar folder, file name font, status bar font, like IntelliJ idea.

Any updates? Anyways, I did a workaround. I increased the size of everything with CMD +, then I lowered the editor font size to desired font-size.

Would also like to be able to change font-family and font-size for specific areas (e. g. the sidebar).
I prefer to see the monotype font "Source Code Pro".

Thanks!

The feature was proposed in 2015, and it's 2020 now ... 🙄

Definitely a wanted feature!

Please add this feature thanks

Please add this

Did you guys expect something different when MS bought Github? I agree with @jerch other IDEs have what we need, it is time to go back to Atom and remember that its development was halted for this IDE one that still holds the name of one of the most bloated pieces of malware I've ever seen in my life, "Visual Studio" - What is keeping us from going back to Atom?

I haven't tried Atom for a long while, but every time I've compared it with VS Code, I prefer Code. Apparently Atom's developers are busy rewriting it from scratch with a Rust backend instead of node. I think this is a mistake, because node with a decent frontend to JS (TS being much more popular than CS is another good point) has adequate performance and reliability for this application IMO, so the difficulty of developing in Rust outweighs the benefits it will bring here.

@realh I think you are completely wrong. Why do you think sublime text is soooo faster than vs code? JS dynamic typing has too much cost thats why asm is getting so much popular. And FYI I don't think atom devs are working on rust backend. If they had atom would be so different today and so fast that nobody would love to use vscode.

See: https://github.com/atom-archive/xray

They have archived it. The benefit of rust is safety and speed which is essential for any software.

Sublime is quite old. In its prime, something like Atom or VS Code might not have even been possible, for additional reasons besides performance. But hardware and browser performance have improved a lot, so that now VS Code probably runs at least as smoothly as an equivalent IDE/editor written in C++ would have done a decade ago. Its performance is adequate. It can keep up with my typing and doesn't suffer from annoying lag in features like Intellisense, even when running on my Macbook Air, editing files over sshfs.

Likewise reliability. Rust is meant to be a replacement mainly for C/C++, not managed languages. The majority of Code's bugs are missing features like this, or things that don't quite work properly (like visual selection in the vim plugin), which Rust wouldn't help with. The sort of bugs Rust prevents are greatly reduced in JS etc compared to C/C++, and would cause crashing and/or corruption of what I'm editing, and I don't see evidence of Code or Atom having big problems with that sort of thing.

If Atom have shelved their Rust-based project, I think that supports my point. I bet they concluded that it just wasn't the right tool for this job after all. Just getting their Rust written and compiled would take far longer than writing and debugging Coffeescript to an equal standard of reliability. By the time they had a complete replacement for Atom, technology would have closed the performance gap and/or made all current languages, including Rust, obsolete. Replacing Electron with something written in Rust would make sense, because Electron is a sort of system, but a text editor is an application, not really what Rust was intended for.

Web assembly is still implemented in Javascript, so I don't think performance is its main attraction yet, but once it gets implemented as truly native it could have a bright future (for gaming, not so much productivity applications). At the moment its main benefit is allowing C++ games which are old, or otherwise have low performance demands, to be ported to the browser.

Sublime is quite old
No it was first released on January 18, 2008 which is not too old only 7 years older than vscode.

"But hardware and browser performance have improved a lot"
But as a general purpose editor it should always be performant. When u run linters, type hints it performance becomes critical. Open a large file performance is essential right? Try opening 2 GB text file in vscode and in sublime text you will realize value of performance.

" The sort of bugs Rust prevents are greatly reduced in JS etc compared to C/C++, and would cause crashing and/or corruption of what I'm editing, and I don't see evidence of Code or Atom having big problems with that sort of thing."
Yes but rust does help when u try to refactor code which is great + point. The cost you pay in rust is long compilation time otherwise its the best language ever imo.

"Web assembly is still implemented in Javascript, so I don't think performance is its main attraction yet,"
I am not getting but wasm will allow to use C, C++ and Rust and the main reason to use wasm is for performance otherwise why we would need wasm in first place?

Anyway vscode is never going to use Rust as they are using Typescript which already has too much cost on compilation. So i don't know why Rust, C++ and C is here.

And Yes i think after ms acquired github, atom has been neglected greatly :(. Anyway Vscode is great editor but this issue is not getting any focus which is sad .

This isn't really an on topic discussion. I've been following this issue for many years now and it seems like the only purpose it serves is for people to workout their frustrations and opinions with others. There's just a ton of noise and no positive updates.

If you want to move on to other editors, you don't need to inform others. Just do it and see if you are happy with your change. In the end most of this stuff is about preference anyway.

This isn't really an on topic discussion. I've been following this issue for many years now and it seems like the only purpose it serves is for people to workout their frustrations and opinions with others. There's just a ton of noise and no positive updates.

If you want to move on to other editors, you don't need to inform others. Just do it and see if you are happy with your change. In the end most of this stuff is about preference anyway.

I agree but that is the best use we can give to this discussion since this will never be fixed by Microsoft, if you want to follow this discussion to finally see it resolved one day, I got bad news for you my friend, customization and giving the developers the right tools to work has never been important to Microsoft, go back to what IE6 was if you want to a history lesson.

I really don't understand the hate towards Microsoft in regards to VSCode. It is hands-down the best editor for any use-case that I've come by...yeah it has it's edge cases where it could be "better" but let's be honest, when we're talking about software and developers needs; "it could be better at x, y, z" will never be satisfied. It's an impossible standard.

That being said, issues like this are here to give visibility to the things our VSCode community really desires as a whole and Microsoft gets to prioritize these things. Thus far I think they've done an incredible job and if anyone wants to continue whining about how bad Microsoft is (in regards to VSCode), then prove it by writing your own massively popular IDE that successfully takes care of all the "x, y, and z" edge cases that should inevitably satisfy everyone equally.

This project is absolutely gigantic and I commend Microsoft for their active work in helping us little devs that can't afford Visual Studio, with a FREE product that fulfills 99% of at least my own requirements and I imagine a whole heap of others as well.

I really don't understand the hate towards Microsoft in regards to VSCode. It is hands-down the best editor for any use-case that I've come by...yeah it has it's edge cases where it could be "better" but let's be honest, when we're talking about software and developers needs; _"it could be better at x, y, z"_ will never be satisfied. It's an impossible standard.

That being said, issues like this are here to give visibility to the things our VSCode community really desires as a whole and Microsoft gets to prioritize these things. Thus far I think they've done an incredible job and if anyone wants to continue whining about how bad Microsoft is (in regards to VSCode), then prove it by writing your own massively popular IDE that successfully takes care of all the _"x, y, and z"_ edge cases that should inevitably satisfy everyone equally.

This project is absolutely gigantic and I commend Microsoft for their active work in helping us little devs that can't afford Visual Studio, with a FREE product that fulfills 99% of at least my own requirements and I imagine a whole heap of others as well.

This is not charity or a gift from heaven, VSCode was put there to gain traction with developers again after losing them for many years, the power of owning the tools we use to create software is worth so much more than any licenses we could pay for it.

@betovelandia And what exactly are they gaining from free users? I don't even share my telemetry and I think I've given feedback maybe once... You can't make outlandish claims and not have proof to back it up, especially if you're actually trying to prove a point...

edit
Let me make clear though that I know Microsoft didn't create this software out of the kindness of their own heart...clearly...but making it out to be some gigantic conspiracy to monopolize developers (for some mystical purpose) seems a bit far fetched...

@Jaeiya

And what exactly are they gaining from free users?

Land.

Which they can use to control or influence every inlet and outlet of it, and by extension every aspect of your codescape.

VSCode is literally a serfdom, or at least the latest MS lame attempt at one.

It's also an excellent piece of software, which MS is ruining, because that's apparently what they do best.

But the really crazy thing isn't that truth. The truly fucked up thing about this is why they outright refuse to implement this feature request. It's such a stupid move on their part, it makes no sense.

@saighost submitted a perfectly good PR years ago, but The Deathstar refuses to implement it. Why?

Seriously, ask yourself that question: Given that it would take less than 3 hours to review and test this extraordinarily popular feature request, why has this not been implemented in 5 years by either the core team, or simply by merging the PR that @saighost so graciously wrote?

Had they just implemented this very simple feature then I would never have gone back to Sublime and realized how fast, smooth, and reliable it is. Sure, it's a massive PITA to customize, but at least it's possible. And once you've got it just right it runs like a dream. Truly sublime.

Congratulations to Microsoft on your 45th anniversary of needlessly kicking developers in the face simply because you're too stupid or stubborn to understand fonts.

Please stop this off-topic discussion now!

Please stop this off-topic discussion now!

The fact that there was a PR ready to fix this seems off topic to you? I wonder if this could be re implemented, it must be an easy fix as @AJB99 mentioned.

Okay, missed that. Can't/ do not want to read such long discussions in parallel to the 40-50 emails in business/ private per day.

Ticket/ issue status is "open". So nobody decided anything. Now let us be patient and see what happens.
If this feature request will be implemented, we'll be happy.
If not (rejected/ closed issue): Stand up.
Today: Subscribe and wait or do it yourself, if technically possible.

I remember one of the official devs saying it isn't that easy; there are other parts of code relying on the size of this font being hardwired. They're probably worried that @saighost's patch hasn't been tested thoroughly enough to iron out any unpleasant side effects. Is there any chance it could be re-implemented as an extension? That would make it easier for more users to try it, then the problems should gradually surface and hopefully be addressed.

This plugin: Customize UI has Implements the features base on the plugin 'Monkey Patch'

Default monospace font for Ubuntu looks too small at 14px in a hidpi screen, but if you set it to a reasonable size then other parts of the GUI are absurdly big (https://github.com/microsoft/vscode/issues/88916). Fixing this issue would also fix that.

OMG! this was a feature request since 2015 😅

This would really make writing code with my relatively poor eyesight better.

Here's a (+1) from me too

It would be very good to be able to set explorer font.

@iliakan doing that you're just pushing for a moderator to lock this issue, just add a thumbs up above because once locked you won't even be able to do that.

I'd say the biggest reason for this issue to be implemented is #84194, which as already said can't be fixed. We have the option to choose between unreadably small text, or large but blurry text with window.zoomLevel. Isn't there any workaround to increase the explorer font size?

I'd say the biggest reason for this issue to be implemented is #84194, which as already said can't be fixed. We have the option to choose between unreadably small text, or large but blurry text with window.zoomLevel. Isn't there any workaround to increase the explorer font size?

This is really why you shouldn't use a web browser to develop applications with, keep the browser for what it's for, do web apps fine, but don't try to make a desktop app a web app.

@Lucretia

This is really why you shouldn't use a web browser to develop applications with, keep the browser for what it's for, do web apps fine, but don't try to make a desktop app a web app.

As someone who used to say this for the longest time, I understand the sentiment. But there are issues electron solves that other GUI frameworks just don't. For one, using anything else is a huge pain in the ass to iterate with. I've done Qt (both C++ and Python), WxWidgets, Delphi, WPF, WinForms, and god knows what, and literally electron is the only one where I thought "hey it's fun to build this desktop app". I'm not even starting with the "cross platform" part. The best experience in "desktop UI" I've had outside electron was ImGui, and that's not even meant for desktop apps. Also note that many apps that have actually good GUIs ended up writing their own and spent a gigantic effort on that, instead of developing the app itself.

But there are other reasons as well. Look at how JetBrains IDEs render fonts, and then look in VS Code. The difference is insane, and you can't even customize things like letter spacing and other features properly in them.

To quote one nice article on reddit:

For a performance sensitive applications like games or number crunching scientific tools the desktop apps are still the only way to go. For everything else a development convenience will be chosen. That’s why everything sucks and all your apps are websites now.

The state of desktop apps is just too sad and horrible.

I think Electron was a good choice, I can't think of anything else at the moment that you can rely on to work so conveniently and well in so many desktop environments.

Add my +1 to the pile. I can't believe this hasn't been addressed in 5 YEARS. Typical Microsoft. 😁

The explorer tree density is way too dense. I shouldn't have to squint to find the file I want. An option to increase the line-height would be nice per https://github.com/Microsoft/vscode/issues/59873

+1

✳️https://github.com/Microsoft/vscode/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Abug==CoC__https://github.com/microsoft/vscode/blob/master/CONTRIBUTING.md💯🦸‍♀️

just a non mentioned yet use case: Make possible to change all vscode fonts to monospace. Some of us (old emacs users) just don't like to switch all the time between variable-width and monospaced fonts while reading.

thought i'd share my shell script to make vscode load CSS from a file (and not complain about being corrupted). i just don't feel like letting extensions do it.

https://gist.github.com/a85b8231a9f5494149387c3a36079e84

i recently had to adapt it to a newer vscode version (or maybe it's because i switched to vscodium) so you may have to change one line to make it work with 1.44 or older.

So what exactly is the reason that we cannot change the font/size in the sidebar? Isn't this a nobrainer? When somebody shows me how to do it I may be able to do it myself.

Yes if someone showed me how to do it, I too could do it. And so could the person who showed me...

any news on this?

any news on this?

Just look above and… obviously, no.

What's the hold-up then? Are there any blockers? I'd like to see some movement on this. 🚀

What's the hold-up then? Are there any blockers?

You can read the answer from the member.

I'd like to see some movement on this. 🚀

We all would like, so we're waiting, or somebody, for example you, can move this.

You still waiting for Microsoft to support customization? We'll find Epstein's killer before this ticket is closed

You still waiting for Microsoft to support customization?

I don't know how to say precisely… I'm not excited, but I'm subscribed, as many people here, and I personally don't use VS Code until at least this issue will be done.

We'll find Epstein's killer before this ticket is closed

I don't see the feature and I don't care about "Epstein's killer". I'm interested in this issue, and, please, let's wait or make. Our comments about "I want this feature!" or somebody's killers don't help.

VSCode team, please hire the HTML layout maker for your Electron-based UI.
They are cheap. All you need is fluid design, just grid or column layout.

You still waiting for Microsoft to support customization? We'll find Epstein's killer before this ticket is closed

Do you think we will find him if I can change the font on my favorite code editor? Maybe he knows how to implement this feature. 🤔

Could you stop the nonsense and just vote +1? You're utterly annoying subscribers and developers. Eventually all you'll get is that the thread will be locked so not even thumbs up might be allowed.

Could you stop the nonsense and just vote +1? You're utterly annoying subscribers and developers. Eventually all you'll get is that the thread will be locked so not even thumbs up might be allowed.

+1

Could you stop the nonsense and just vote +1? You're utterly annoying subscribers and developers. Eventually, all you'll get is that the thread will be locked so not even thumbs up might be allowed.

Nope, we can't. And if they do this I'll be using a different Code Editor. I already use 2 on a daily basis. VS CODE is ONE option from many good options. Problem Solved :)

Now, why this isn't a feature? 5 years have passed.

And if they do this I'll start using another Code Editor.

I think, you wrote incorrect, but: OK, please start.

Now, why this isn't a feature? 5 years have passed.

Because nobody has implemented this, obviously.

The lack of font alternatives makes the application difficult for anyone who requires large text. I didn't see a specific discussion of this as an accessibility issue, but this is a big deal when it comes to enabling developers with all levels of physical ability. Relying solely on OS accessibility features is not a great solution. (Try doing dev work while using MacOS zoom, for example.) I've tried various CSS hacks, I've only been able to get them partly working.

I normally use a plain text editor because I can make my terminal font anything I want. But I'm currently in a situation where I basically have to use vscode. It's pretty discouraging to look for a solution to the tiny explorer font and find this five year old feature still open.

Maybe this issue should have the accessibility label?

@feorlen - You can already customize the integrated terminal's font and size independent of the editor. Unless I misunderstood your ask.

@narfanar I believe @feorlen means s/he normally uses terminal based editors (vim, ecmas, nano, etc.). So changing the terminal font size will affect all editor "UI"s.

@feorlen Have you tried the window.zoomLevel setting? I think it's better than nothing.

And if they do this I'll start using another Code Editor.

I think, you wrote incorrect, but: OK, please start.

Now, why this isn't a feature? 5 years have passed.

Because nobody has implemented this, obviously.

Wow, genius comment.

I am not sure if my request is same as this issue..
For now, I modified workbench.desktop.main.css: search windows{font-family:Segoe WPC,Segoe UI,sans-serif} in the file, and add the fonts I need into it. For Mac and Linux just search mac{font-family or linux{font-family.
I did that just because I have some cue sheets with file name in CJK, and fonts in sidebar and tabs will fallback to a certain system default pixel font (It seems like).
I hope VS code can provide the option to change UI fonts like we change editor fonts in the setting.json

Just moved to VSCode from Atom. Blown away that my "file tree" has to look so big and bold and bright. Compare with atom:

VSCode:

atom:

I'm sure I sound crazy ... but see how nice and subtle atom is? The VSCode explorer distracts from the code (editor).

Getting close to finding Epstein's killer, I got a list of suspects, how's this feature coming along?

@justinko, contrast is important. I'd hazard a guess that a large number of people find it non-negligibly more difficult to read the text in the Atom screenshot than that of VSCode. Personally, I don't perceive a difference, to such an extent where I skimmed your comment at first and thought they were both screenshots of Atom. Having realised the first is of VSCode, I'm now having trouble figuring out what you're bothered by — IMO, the VSCode one is less "big and bold and bright"; smaller icons, and folder icons are all grey.

In any event, your comment probably concerns font colour rather than/in addition to font size, but these are all things that ought to be configurable.

@feorlen pointed out that this is an accessibility issue, and I think that is a great point! SF Monospaced seems to be the only font that my dyslexia can get used to, and reading the file explorer without it is such a pain.

Please please please someone at Microsoft, please look into this! Being visually impaired, I have to get within two inches of my screen just to read the font in the Explorer window just to be able to rename a file and make sure that I have the characters I'm inserting into file names in the right place. The editor window being adjustable in font size is great and I have mine set to 18 just to be able to read it. This is all well and good, but the rest of the UI needs the same kind of customization options, especially if you're using VS code on a computer via RDP where having Windows scale everything isn't an option. It is definitely an accessibility issue and needs to be addressed after almost five years since it was first opened.

Why is a feature that is obviously such a simple thing to add taking so long? It's an accessibility nightmare, it's easy to do, and yet - here we are years later still waiting. This makes no sense.

Could you just vote above to express your preference? This kind of comments only make that interested people get unsubscribed from the issue or, worse, that the issue gets restricted so you can't even vote. Can't you realize that doing what you do goes against your own interest?

Why is a feature that is obviously such a simple thing to add taking so long?

Yet Another Reference to a member's answer: https://github.com/microsoft/vscode/issues/519#issuecomment-643326100

Microsoft never cared for UX, you guys can subscribe, unsubscribe, vote, talk, stay quiet, or even find Epstein's killer and nothing will change the fact that this will never see the light of day because that's Microsoft.
Many Engineers here might be new to dealing with them but this attitude has been constant since the days of IE6, Microsoft just want to have a strong presence on web, but Microsoft caring for developer tools and customization? never gonna happen.
Atom was great, Atom was customizable from the beginning, then came Microsoft and ruined everything by buying Github.
And we are going to give @memeplex a heart attack if he keeps getting notifications from this thread so please just +1

Can we lock this thread to contributors for now?

There are several things needed for this feature request to work as expected.

• Inline icons need to resize to font height (if SVG) or closest pixel perfect available size (if not SVG).
• Size ratios between all the different font elements in the workbench need to be maintained, otherwise you can break the UI completely.
• Sidebar icons need to be adjusted as well (you can't have a huge sidebar close to a tiny explorer view).

My guess is that we need something similar to the window zoom level setting, so a scaling factor, but one that only affects the workbench (or should I say, the application shell) and NOT the code editor (where line height needs to remain pixel perfect and integer based).

The application shell is not affected by line height issues so a scaling factor here shouldn't cause any issues. (perhaps it might, with the popups and the explorer tree... I'm not sure if those are rendered line by line.)

This is not an issue of looking better for me, and it's not good enough to scale up the UI and decrease the editor.

The most serious problem is the weight of the font. You've chose an extremely thin font which I'm sure is great for young people with great eyes, but is terrible for some of us. No amount of scaling or colors or high contrast will make the font any better this way.

This is a serious accessibility issue. It hurts my eyes to use this app, and I have to use it on a daily basis.

I can't just wear glasses to fix it up.

I have to join this request. I have to deal with frequent headaches and the font and colors of the applications I use have a lot to do with making them worse or better. The source of this app does not help me at all and is probably the only thing that makes me abandon it from time to time.

wow 5 years and this feature still isn't even a thing lmao. I like vs code but this is absolutely necessary if you have more than one screen.

Meanwhile we just keep on changing by hand .part>.content{font-size:13px} to .part>.content{font-size:16px}
Anybody that says it is more complicated than that is just full of it. How hard can it be to update a CSS based on a selected font-size? I guess it is for MS.
Now at every upgrade there are TONS of useless features that probably take a lot more time than adding a setting to set the font size of the file tree. WHAT THE F ?

Meanwhile we just keep on changing by hand .part>.content{font-size:13px} to .part>.content{font-size:16px}
Anybody that says it is more complicated than that is just full of it. How hard can it be to update a CSS based on a selected font-size? I guess it is for MS.
Now at every upgrade there are TONS of useless features that probably take a lot more time than adding a setting to set the font size of the file tree. WHAT THE F ?

Basic question. How do you add this/edit this in VS Code?

@KingOfSpades edit workbench.desktop.main.css and look for first .part>.content

you can change font of editor, of terminal, but for some reason you can't change panel font

typical microsoft, just like windows 10, they love inconsistency and bloat