Improve settings editor by adding better visibility to defaults, user and workspace settings so the user can easily tell which is currently being used.

[julie777]

Currently the settings editor lets me toggle between workspace and user settings. I can't tell if a value is the default, I can't tell what is overriding what.

Make all four sources of settings editable in the settings editor.

Currently you can choose to edit user or workspace settings, and for some settings you can jump to the settings file. However, this doesn't enable you to see the default settings, or to edit the settings files that many build tools use. (Putting settings in a config file for the tool instead of in the vscode settings is a best practice so that actions in vscode mirror actions during the production build. Examples, eslint, etc. should always have their settings in a config file and not set in vscode because the build should run the tool the same was as vscode.)

Current Settings Editor

Here is a current example from vscode.

Considering the setting for "focus recent editor after close" I can tell that I am looking at user settings and that the workspace setting has been modified. It is not clear to me what the default is, or what the current value is.
(Firefox gets this partially correct in about:config by showing the defaults and the items that have non-default values. It fails by not providing documentation for each item.)

Show all sources and values at the same time.

Show all sources at the same time and show the computed value that will be used. This gets rid of switching between user and workspace settings, shows where the current value is coming from, and can include default and config files for tools.

My proposal would be to provide a more table-like view:

This is a very rough example and I believe the actual layout can be much cleaner, but it shows the default, the changes, including empty for a source that is not set, and the actual computed value which will be used. Note, that for extensions, such as Prettier, only the config file value would be available by default. I will mention a way for vscode to have more information for extensions and tools farther down the page. In the above table paths without values can still have a description, such as workbench.

Improvements

Tree View

As for improvements, the current settings editor has a partial tree view of settings to the left.

Using a treeview for the path column can support expand, collapse, aggregating tool config files into the tree, etc.

Defaults for Extensions and Build Tool

Using the vscode default settings from vscode settings which has default values and some documentation, we can envision that any extension/tool could provide a default file, so in addition to prettierrc.js I could have a prettierrc.defaults.js that has a format slightly extended from the vscode defaults. (I just used a couple settings for demonstration.)

prettier: {
  tabWidth: {
    default: 2,
    type: "number",
    description: "number of spaces per indentation level",
  semi: {
    default: false,
    type: "boolean",
    description: ["true - Add a semicolon at the end of every statement."
                        "false - Only add semicolons at the beginning of lines that may introduce ASI failures"],
  },
  trailingComma: {
    default: "es5",
    type: "string",
    values: ["es5", "none", "all"],
    description: ["es5 - Trailing commas where valid in ES5 (objects, arrays, ...",
                        "none - No trailing commas.",
                        "all - Trailing commas wherever possible (including function parameters ..."
                       ],
  },
}

With the necessary information in the defaults file vscode can change presentation based on types, such as boolean, or using trailingCommand as an example, validate the values, or show them in a dropdown menu.

[julie777]

After wasting a couple hours today because of workspace and user settings interacting badly, I that changing the way settings are displayed is even more important. As it is currently there is no way to see what is actually being used for any setting.

[julie777]

Based on my debugging today, I have a further suggestion for the settings page.

Workspace settings should be checked in to Git with the project so that everyone working on the project has the same settings. (What I saw in the documentation.) The biggest reason for this is that many people put tool settings in vscode settings instead of in separate config files for the tool.

[julie777]

I spent a lot of time reading documentation and running tests.

It turns out that a better settings editor would really help because there are too many places settings come from.

This is the actual search order. The last one that has the specific setting set to a value wins.
default settings editor.tabSize
user settings editor.tabSize
workspace settings editor.tabSize
directory settings editor.tabSize (multi root workspace)
default settings [Python] editor.tabSize
user settings [python] editor.tabSize
workspace settings [python] editor.tabSize
directory settings [python] editor.tabSize (multi root workspace)

This means that somehow finding what the currently being used setting value is can't be reasonably done by the user and should be done in the settings editor.

[rzhao271]

Closing in favour of #58038