search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.14k stars 29.28k forks source link

Split JSON settings editor discussion #125952

Closed roblourens closed 3 years ago

roblourens commented 3 years ago

I'd like to start a discussion around simplifying the split JSON settings editor to make it easier for us to maintain.

Keeping "deprecated" features around for a long time is not free and leads to a trail of tech debt that costs developer time that could be spent improving other areas of VS Code. It also represents many lines of code, and as the complexity and download size of VS Code grows, we need to take available opportunities to reduce it. I know it still has some fans, but telemetry shows that it is used very little compared to other features.

I want to think about how to keep some of the benefits of the split JSON editor implemented using typical VS Code UX patterns, rather than custom code just for one editor. Reading through past discussion on the settings editor, it's clear that the most valued element of the split editor is the ability to read the default settings and the user's overrides easily on one screen. We can actually do this easily in VS Code by showing the default settings as a simple text editor side by side with the overrides using the same sort of split editor that we use for diffing.

image

This lets us clean up code related to the custom search bar, the scope switcher, the pencil icon for editing settings, and some other UI decorations. We could even have an action to toggle the default settings split on or off, which would make this feature useful to people who currently just use the basic json editor. I think this plan is a good balance between serving this user workflow and software maintenance cost.

The settings editor GUI remains for fuzzy search and switching scopes quickly.

eamodio commented 3 years ago

While I will miss the fuzzy search filtering, I think this is a good compromise. As for switching scopes, could we maybe just have a toggle button in the editor toolbar to switch from user to workspace settings?

roblourens commented 3 years ago

I had the idea of adding a quick access for switching scopes:

image

For example, the settings prefix would show User, Remote, Workspace, Folder1, Folder2

eamodio commented 3 years ago

Not sure I'm following exactly -- typing settings would list the available scopes and then open either the GUI or JSON based on your settings? I still think a quick toggle in the editor toolbar would be helpful -- but maybe the button just shows a menu with those same choices (User, Workspace, etc)

roblourens commented 3 years ago

Just JSON. Since the GUI has it's own scope switcher. And yeah it could also be launched by an editor action.

jeanp413 commented 3 years ago

Oh no! I've been using the split JSON editor since the beginning. Hope there's more feedback from the community to reconsider this decision if possible :disappointed:

eamodio commented 3 years ago

@jeanp413 What features of the split json editor would you miss that won't be addressed by this? I've also used the split editor since the start and I will definitely miss the filtering, but I don't think I will miss too much else.

jeanp413 commented 3 years ago

@eamodio Definitely the search box to filter the settings and the pencil action to quickly add it to my settings.json instead of typing or copying some setting

kkm000 commented 3 years ago

The fuzzy search box is priceless. That would be a huge loss of productivity for me. I can copy stuff between panes manually, but it seems to me that finding that setting without fuzzy search would be simply impossible. Now it's so intuitive that I am finding what I want to change by trying 2-3 fuzzy searches, and sometimes hit the bullseye from the first attempt. Please keep it if at all possible. Pretty please.

It's like Emacs Ido mode, only much better. Please don't kill it.

carlocardella commented 3 years ago

I second @kkm000 about the fuzzy search. Using the GUI for fussy search, copy the setting id and then move to the json settings editor seems to overcomplicate things, I see lots of back and forth between panels and frustration in my future if the fuzzy search in the json editor goes away...

NatoBoram commented 3 years ago

There's many places where the split JSON settings could be improved while it's changed and these changes should be reflected in the rest of the editor, without being tied to settings specifically.

These improvements could work in many split-panel scenarios, like editing i18n files in a project.

I hope you will consider how awesome the split JSON settings editor is and add its features to the rest of VSCode before removing it. It really is the #1 best feature of VSCode.

wenfangdu commented 3 years ago

The current settings JSON split editor is one of the best features of VSCode, using it from the start, tried the UI editor, never got used to it. Please don't nerf it 🙏.

kandros commented 3 years ago

This settings page was the first feature that really pushed me to give VSCode a try, is so natural to use and easy to share settings

If I had to choose only one it would be JSON view 100%, the GUI is cumbersome

Please keep it 🙏

OneOfOne commented 3 years ago

Please leave the json settings editor, the GUI one is annoying to use.

rs1052 commented 3 years ago

The split JSON editor makes it easy to see exactly what is overridden in the user settings, workspace, and folder at a glance. The features being cited to removed (custom search bar, the scope switcher, the pencil icon for editing settings) streamline the experience. JSON should go back to the default, in my opinion. Telemetry is showing not a lot of people using it because the default was changed to the UI version, that doesn't make it superior. I'd also guess that those who went in and changed it may have also disabled telemetry.

I'm not too knowledgeable in the code for these features but what are we talking about in terms of actually maintaining these? It's only tech debt if it is costly (paying "interest" on that debt). As you said, it is custom code just for one editor, can't it exist and function without any need to constantly update it? It is a JSON editor with features on top, which doesn't seem like it would be in flux all the time. If it were intertwined with a bunch of other features, yeah I could see that being a headache and a huge slowdown.

I'm not sure I'm buying the download size either, how much larger are we talking? Surely there are much bigger fish to fry when it comes to the app size.

zaatas commented 3 years ago

Should this occur, I'll leave VScode!! I will take the dive and make the investment into Neovim and Lua.

pcjmfranken commented 3 years ago

If there are only resources to streamline and maintain either the visual menu or the JSON editor, can we have a pol which one to keep? And to save some time, work on removing the visual menu can start right away :)

But in all seriousness, to me, some of the JSON view's main benefits are:

The visual editor will never come close to the JSON one in those areas. I do not believe that the minor seeming benefits of the proposed changes outweigh the negative impact those will have on the things that make the JSON editor so fantastic!

Mellbourn commented 3 years ago

I would really miss the ability to comment my settings. I often write explanations for me to remember motives for specific settings.

JohnSpindler commented 3 years ago

I would really miss the ability to comment my settings. I often write explanations for me to remember motives for specific settings.

+1 to this in addition to adding in some clarifying notes for myself when a setting isn't documented in a way I understand.

ZUIcat commented 3 years ago

I don't like GUI, I would rather remove GUI instead of Json.

roblourens commented 3 years ago

I agree that the fuzzy search is useful, and it would be interesting to experiment with a way to search settings using this same search logic using a quick pick control. This seems like a way to tackle it that works within existing VS Code UI conventions, without changing the meaning of the basic editor find widget, or other special logic. It's hard for me to think about how to apply the fuzzy search (or pencil icon) to generic JSON documents since it's implementation is very settings-specific, and I don't think there are other real examples of this split pane defaults/overrides editor pattern.

@ryan3E0 It feels like it should be a standalone thing that we never have to touch, but it exists as a component within a larger system that is often in flux. For example, as we've made changes to how opening an editor works in VS Code to support custom editors and notebooks, we recently had to spend a lot of developer hours changing the split JSON editor code to adapt to these changes. And we periodically make cross-cutting changes across the entire codebase or across feature areas which can impact this code.

Just in case this point gets lost in the thread, I want to be clear, the thing that is being changed is only the custom split-pane JSON editor. Editing settings in a JSON file will never go away.

carlocardella commented 3 years ago

@roblourens, I think the quality of the JSON settings editing experience is important. I understand the JSON settings file will not go away (a similar point was discussed the last time this topic was brought previously: #62964) and I do not have a reason to doubt you guys are motivated to do what is best, but I also understand why people may be wary of this change.

For comparison, Atom (I just installed it after a really long time to check) has eerily similar Settings and Keybindings GUIs and offers the ability to edit the config file directly (it's yaml in Atom's case). Anyway there is no advanced editing experience, there is no intellisense, I have not found a way to have a side-by-side view with both default settings and my settings (which as other mentioned, I found invaluable to learn about settings and their use, and see at a glance what is the default and what I am using as override). In other words, it is not really usable (one might as well just open the file in Notepad).

So, I understand things will change (I'm not sure how much room for discussion is left since this issue is already scheduled for the July release), I really hope the experience will not degrade too much. It would be a real shame.

You know what? I would be really curious to see the reaction if you opened a similar issue to remove the Settings GUI, I'd be curioius to see how many people would miss it :smile:

kkm000 commented 3 years ago

@roblourens, I hear you, and I think that I understand this feeling. I have been a software engineer for most of my working life, and I know that some parts of code look like a burden. I experienced this too many times: a feature is a mess, and it just does not fit the rest of design, but users like it. This happened both in open-source and for-bread-and-butter projects. You see how many people came here to say how they find the feature indispensable. And sometimes it takes more effort to keep something alive, but it's a gratifying effort.

Think of this. I have read Raymond Chen's blog for years, and his book too, and can relate to engineers having to jump through hoops on fire to keep the Windows features that even make no sense—like keeping it backward compatible with bugs in enterprise software whose developers had been long out of business. That's necessary for Windows business, but not really a gratifying part of the job. And here you have two dozens of flesh-and-blood GitHub nicks fellow engineers begging to keep the feature. Yes, that's a minuscule number compared to the total number of VSCode users, but we're not just a number, we're the real hardcore ones who push the pedal to the metal. And there are much more who did not notice the announce, or were too busy to voice their displeasure. Please think of all of us who you can make happy by keeping it, or an equally efficient equivalent.

Settings is always a tough topic to discuss; a complex highly customizable environment—take Visual Studio, VSCode, Emacs—have thousands of them. For example, key bindings in Visual Studio have a search box, but it first appeared in VS2012, IIRC. How tortuous was it to simply change a key binding back then. VSCode beats the other two in this small sample in its simplicity of finding and changing what you want to customize: Emacs has M-x apropos to search both customize variables and descriptions, not fuzzy; Visual Studio does not have anything even close for settings; neither comes close to a fuzzy search in a single pane which reflects the changes as you type.

Then, for VSCode it is much more essential than for Emacs. For the latter, there is Emacs.SO where I can go and find or ask about a particular customization. VSCode is very agile, and in my experience the vast majority of customizing recipes that I'm finding on the internet do not work any more when they are a year or two old, without minor or major tweaks. Options search is perhaps the only way for advanced users to keep up with the changes. It's not a "nice to have" feature. It's an essential feature, really.

the custom search bar, the scope switcher, the pencil icon for editing settings, and some other UI decorations

The main sticking point for me is the custom search bar. Scope switcher is nice to have, but it's already incomplete in remote development: the UI editor has all three scopes, user, workspace and remote ssh; this switcher omits the remote scope. The pencil icon more often failed on me than not with a cryptic error (in essence, "files have changed, try again", but this did not go away with saving a file, or adding-removing a space and saving it). Search bar is of essence: when I know what to change or to try, I can copy-paste or type, very fast thanks to autocompletion; this is not a big deal. Knowing is.

jeanp413 commented 3 years ago

@roblourens, I didn't know this is the third time (after #62964 and #64932) bringing up this subject, somehow I missed those previous discussions and surely many other people missed them and will miss this one too. So, if you are looking for reasons to not simplify the split JSON editor, you should revisit those previous discussions where the stated arguments against doing it are in concord with the ones stated here.

carlocardella commented 3 years ago

@roblourens would it make code maintenance easier if the split JSON settings editor as we see it today was a built-in extension instead of part of the main product?

I know logically a settings editor should be part of the main product but if functionally for users the JSON settings editor can remain as it is today, if it will simplify the main VSCode codebase and the split JSON settings editor can be maintained and receive future improvements, then it may be a good compromise to consider?

thernstig commented 3 years ago

I would be a bit vary of this statistic:

telemetry shows that it is used very little compared to other features

That might very well be true looking at the numbers only. But if we recognize that the GUI editor is the default and people are not aware of the split JSON editor, and they had an option to select either or when installing VS Code, it would be a much more fair comparison.

Statistics is what it is, you can prove any point if you don't take a holistic approach.

ladyrick commented 3 years ago

https://github.com/microsoft/vscode/issues/62964 has 49 👎 .

https://github.com/microsoft/vscode/issues/64932 has 19 👎 .

And this issue has 29 👎 for now.

Why are you so confident to delete the split JSON settings editor?

Split JSON settings editor is not a tech debt. It's a great feature of VSCode. It's the best way to handle large number of config items.

Your effort spent to maintain this feature is valuable. Please don't remote it.

carlocardella commented 3 years ago

telemetry shows that it is used very little compared to other features

That might very well be true looking at the numbers only. But if we recognize that the GUI editor is the default and people are not aware of the split JSON editor, and they had an option to select either or when installing VS Code, it would be a much more fair comparison.

Good point @thernstig. I would add that comparing the settings editor "to other features" may be misleading, it depends on which other features one uses for comparison. I assume people do not need to change settings all the time, the pure number of "settings update" events will of course be relatively low. Again, I think it would be interesting to compare the JSON settings editor telemetry with the GUI editor, keeping in mind that the GUI version is the default, therefore guaranteed to have higher usage for the reasons @thernstig mentioned (and more, I'm sure).

lijh8 commented 3 years ago

Click on the UI and set them one by one, NO! 👎

This is the first setting I'll change. It's better to make json the default and kill the ui option:

    "workbench.settings.editor": "json", //ui,

I just got 57 settings so far. I edit them and sort them by alphabet manually. I copy and paste the json content when I'm on a new machine.

I like these 2 best. They make the text very easy to read:

    "editor.fontSize": 14,
    "editor.fontWeight": "bold",
{
    "breadcrumbs.enabled": false,
    "C_Cpp.errorSquiggles": "Disabled",
    "C_Cpp.formatting": "Disabled",
    "C_Cpp.updateChannel": "Insiders",
    "debug.showBreakpointsInOverviewRuler": true,
    "diffEditor.renderSideBySide": false,
    "editor.autoClosingBrackets": "never",
    "editor.autoClosingQuotes": "never",
    "editor.dragAndDrop": false,
    "editor.folding": false,
    "editor.fontSize": 14,
    "editor.fontWeight": "bold",
    "editor.hover.enabled": false,
    // "editor.lineNumbers": "off", //
    "editor.minimap.enabled": false,
    "editor.renderLineHighlight": "all",
    "editor.roundedSelection": false,
    "editor.rulers": [80], //
    // "editor.wordWrap": "wordWrapColumn", //wordwrap
    "explorer.confirmDelete": false,
    "explorer.confirmDragAndDrop": false,
    "explorer.openEditors.sortOrder": "alphabetical",
    "extensions.ignoreRecommendations": true,
    "extensions.showRecommendationsOnlyOnDemand": true,
    "files.exclude": {
        "**/.build":true,
        "**/CVS": true,
        "**/._.DS_Store": true,
        "**/.DS_Store": true,
        "**/.git": true,
        "**/.gitignore": true,
        "**/.hg": true,
        "**/.svn": true,
        "**/.swiftpm":true,
        "**/.vscode": true,
        "**/*.d": true, //dep files
        "**/*.o": true, //obj files
        "**/*.qbk": true,
    },
    "files.insertFinalNewline": true,
    "files.trimTrailingWhitespace": true,
    "git.autofetch": true,
    "git.enableSmartCommit": true,
    "http.proxySupport": "off",
    "outline.showArrays": false,
    "outline.showBooleans": false,
    "outline.showConstants": false,
    "outline.showEnums": false,
    "outline.showFields": false,
    "outline.showVariables": false,
    "window.title": "${activeEditorLong}",
    "workbench.colorTheme": "Default Dark+",
    "workbench.editor.untitled.hint": "hidden",
    "workbench.settings.editor": "json", //ui, json
    "workbench.settings.useSplitJSON": true,
    "workbench.startupEditor": "newUntitledFile",
}
roblourens commented 3 years ago

I think that making the comparison to Windows' efforts for backcompat is useful in that it illustrates how different the two products are in what our goals and values are, our development resources, and what people like about them. Do people say they appreciate that vscode will jump through hoops to maintain every feature for years, or that it is lightweight, agile, and focused on the essentials? 😁

Hadn't thought about it much, but I think it would be possible for an extension to implement a settings editor. Porting something like the split json editor to a webview editor extension would be a substantial amount of work, would require bundling an editor in the extension, and isn't something that we would do. The URIs for the settings schemas are here: https://github.com/microsoft/vscode/blob/37a11814295fe9e90542d8990c30b83bb2de42fd/src/vs/workbench/services/configuration/common/configuration.ts#L18

pcjmfranken commented 3 years ago

jump through hoops to maintain every feature for years, or that it is lightweight, agile

Nope, you're absolutely right! We're starting to get through to you I see 😉

An impractical GUI editor that will always be lagging behind core features/API developments on a functional level, but then also has a bunch of UI components that aren't really used anywhere else in the entire editor that require constant upkeep. Doesn't sound very lightweight and agile to me, more like a high overhead costly blocking factor.

A JSON editor on the other hand.... I mean, here, from the official language description:

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate.

1+1=

roblourens commented 3 years ago

@pcjmfranken Just in case it's not clear, the thing that is being changed is only the custom split-pane JSON editor. It seems like the points you've brought up are mainly relevant to editing JSON in a basic text editor as well. Editing settings in a JSON file will never go away.

pcjmfranken commented 3 years ago

@roblourens A fair point that's easy to forget and good to be reminded of!

I guess, how I personally see it, is that the functionality that you are aiming to remove is essentially the cherry on top of a really awesome cream pie, whilst telling us that your pecan pie isn't too bad either. I like the cream pie better though (and who wouldn't, right?!), and let's be honest it's just not the same without the cherry!

lonix1 commented 3 years ago

Agree with all users here, we'd like the json config "experience" to stay. If changes must be made, then please at least ensure that the new editor has the same features/ux as the old one.

And while you're at it, please ensure the various bugs in the current editor don't make it into the new one:

Interested to see what you guys come up with. Thanks for involving us.

angel3cu commented 3 years ago

I would like to give a thumbs up for the classic JSON settings editor. I have NEVER actually used the UI editor, due to the large amount of settings available on VS Code. I currently have more than 1,000 different settings in total which is impossible to maintain using the UI. My actual JSON settings file is 274 lines long!

If I had to choose, I would keep the JSON editor instead of the clunky UI. I understand that editing JSON files will still be possible anyway, but the current editor makes it easy by providing a searchable list of available settings and suggestions for the possible values for each of them, as well as warnings when any of the settings in the file are not used anymore (which helps keep the settings file clean). Any improvements to it are welcome, but please do not remove it. 🙂

carlocardella commented 3 years ago

The fuzzy search bar is gone in today's Insiders. Now to search for settings one must use the GUI and then switch back to the JSON editor (while it is still around in this mutilated form). Bad productivity and workflow impact 👎😫

carlocardella commented 3 years ago

The pencil is also gone. At least settings autocomplete still works.

Another side effect (this will likely have a more limited impact): I had a custom keybinding to search my settings (below), this no longer works since the editor is no longer recognized as "SettingsEditor"; is looks like a simple file where ctrl+f invokes the search widget

{
    "key": "ctrl+shift+f",
    "command": "actions.find",
    "when": "inSettingsEditor"
}
carlocardella commented 3 years ago

I have disabled automatic updates in Stable, I think I'll stick to 1.58 till I absolutely have to upgrade

"update.enableWindowsBackgroundUpdates": false
OneOfOne commented 3 years ago

Good ol' microsoft...

majority of users like and use feature X microsoft, nah, add Y and make it the default majority of users ignore Y microsoft, well, i wasted time developing Y, so screw all those people, I'll just remove X and keep Y as the only option.

Oh well, at least it's open source, we all can just switch vscodium or neovim if it comes to it.

Also you're using telemetry as a metric, however did you factor in that the majority of users who know how to use the json editor will more than likely disable telemetry?

Please reconsider, there are so many other bugs that's been open for years that could use more love instead of deleting a feature that works.

roblourens commented 3 years ago

I've pushed a change to replace the split JSON editor with the simplified split JSON editor - just two panes with defaults and settings.

@carlocardella the pencil should still be there! I realized that we already used this in the basic settings.json file, so I've left it, contrary to what I said before.

jeanp413 commented 3 years ago

I've pushed a change to replace the split JSON editor with the simplified split JSON editor - just two panes with defaults and settings.

@roblourens so what was the point of creating this issue and calling it a "discussion" if you are gonna ignore us all and do it either way 892785264b4682d102b9cb81e01a549c218a74ee ? :-1:

the pencil should still be there!

Personally, the pencil is more useful when it's on the left pane which is now gone. Anyway, the most useful feature is the fuzzy search box which is gone too, now it feels like opening two notepad windows side by side.

carlocardella commented 3 years ago

@carlocardella the pencil should still be there! I realized that we already used this in the basic settings.json file, so I've left it, contrary to what I said before.

@roblourens, no, the pencil on the left pane (which is where it was most useful) is gone

carlocardella commented 3 years ago

History repeats itself apparently: https://github.com/microsoft/vscode/issues/64932#issuecomment-447093051

I can only hope it will repeat completely and, as that December over 2 years ago, the decision is reversed. I will not upgrade beyond 1.58 unless absolutely necessary.

pcjmfranken commented 3 years ago

The fuzzy search box is probably the most useful feature. Very disappointed to see it go!

@jeanp413 makes a very good regarding telemetry data representativeness. It could very well be that users who prefer the JSON editor are more likely to disable telemetry. This is the case for 3/4 devs I discussed this with earlier today.

roblourens commented 3 years ago

the pencil should still be there!

Personally, the pencil is more useful when it's on the left pane which is now gone.

Ah, yes, sorry.

I know this isn't much, but I was wondering whether it would help with search to be able to open a settings UI editor to the side. Then you'd be able to search there on the side while still keeping your focus on the setting.json text editor.

carlocardella commented 3 years ago

Something like this (here I'm just showing the Settings GUI and my actual JSON settings side-by-side, didn't have time to play with a more realisting mockup)?

It looks like an ugly Frankenstein to me, an hack just to save a few clicks and open the JSON file side by side like this, I do not see a real benefit. On the usability I have doubts but I would need to try it once first to be objective.

image

NatoBoram commented 3 years ago

The JSON settings editor was gutted, but none of its features made their way to the text editor.

All of these are improvements that should've been ported to the text editor before the settings editor was gutted.

I'm sad that you did not consider how the settings editor made VSCode the behemoth it is today. Without it, VSCode would be nothing today.

carlocardella commented 3 years ago

I do not know if VSCode would be nothing without the JSON settings editor but it is definitely a huge part of why I like and use VSCode every day instead of Visual Studio, or Atom, or other editors. I suspect I am not alone.

VSCode allows to customize and fine tune every little detail, from appearance to how the editor behaves, how extensions behave, keybindings, the ability to install it on a new machine and be up and running with all extensions and settings sync'ed in just a couple of minutes and so on; all this flexibility has no price for someone who spends hours each day in the code editor.

VSCode is the first editor I really felt mine and I spend time to try out and improve these customizations and I like to keep them well organized. Most of that would simply not be possible with the GUI editor. Jumping back and forth between the two would be even worse.

kkm000 commented 3 years ago

@roblourens:

I think that making the comparison to Windows' efforts for backcompat is useful in that it illustrates how different the two products are in what our goals and values are, our development resources, and what people like about them. Do people say they appreciate that vscode will jump through hoops to maintain every feature for years, or that it is lightweight, agile, and focused on the essentials? 😁

You first build a strawman out of my words, reading into them a comparison of efforts for backward compatibility between VSCode and Windows, which is just not there, and asserting that I said that every feature must be maintained, although neither I, nor, to the best of my knowledge, obviously didn't. Yes, of course, in your exposition I do indeed look like an idiot throwing nonsensical comparisons and irrational requests. Then you beat this strawman victoriously, then add that grin-in-your-face thing. And you're speaking for Microsoft. Okay. I admit that my appeal to your presumed engineering professionalism and the sense of satisfaction with your work was a logical error.

I joined the Insiders to provide feedback and contribute to the product development, not to spend my only lifetime on participating in mock "discussions" only to be made a laughing stock of by a Microsoft employee. As @carlocardella said, 1.58 Stable is a good choice. With telemetry off, naturally: it's none of Microsoft's business. I'll do my best not to assist your employer in any way in future, as long as it condones the public speaking policy of its employees mocking its customers.

By the way, you introduced what looks to me like a bug into the editor (maybe it's another "enhancement", I have no idea). The open settings.json tab now has no path name. Not in the title bar, not in the tab tooltip. So I have open tabs with settings.json, settings.json and settings.json, and am trying to figure out which is which. The only way to discover the path is through the Explorer Open Editors section, where the path can be copied via the Copy Path command then examined by pasting it somewhere. If that is intentional, please do not waste your time on mocking me again: I've signed off updates to this thread.

hsimpson commented 3 years ago

I know it still has some fans, but telemetry shows that it is used very little compared to other features.

The reason for this is, because the professional users use the JSON split pane editor because in enterprise environments and multiple projects this is much more productive then the fancy GUI Editor.

But the majority of users are probably not enterprise driven or multi project users, or sometimes beginner users who stick with the default. So the telemetry data for this is uselses in my opinion.

x80819091 commented 3 years ago

Let's make this the MOST downvoted issue on the VSCode repo!