Settings editor not showing inherited values in workspace scope

[yhvicey]

• VSCode Version: 1.27
• OS Version: Windows 10 1803

Steps to Reproduce:

1. Set some value to true in your user settings, like editor.formatOnSave:
   

2. Open settings editor, switch to Workspace Settings, you will see the item is unchecked but showed (modified by user):
   

3. If you want to set editor.formatOnSave to false in this workspace, there's no way to achieve this. If you check & uncheck the item, there will only be an empty settings.json file in .vscode folder:
   

Does this issue occur when all extensions are disabled?: Yes

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• New settings editor: workspace does not inherit settings (#55203)

[roblourens]

That's correct - we decided to consider this an "advanced" feature that you can still configure in the json file, but not in the settings UI.

Showing a setting that's configured to its default value is a confusing UI experience, I'm still open to supporting this in the future though.

[yhvicey]

According to settings override order (Workspace Settings > User Setting > Default Settings), shouldn't workspace settings editor showing values inherited from user settings? If so, we can override values in workspace settings editor.

[roblourens]

I thought it would be less confusing to show always show the default unless a setting is modified in that scope.

[yhvicey]

Since there's a notice after the item (Modified in: User), I thought this won't be that confusing for users. These two settings (User and Workspace) are not parallel, so maybe we don't need to show default values in both editor?

[roblourens]

From #58901

(not sure if this is a feature request or a bug, since it was intentional)

Default settings may change.
When users explicitly set a setting to a value, they expect to have a guarantee that the setting they chose explicitly will not change in the future, even if the default happens to change.

However, when you use the new settings editor to change a setting back to a value that happens to be the default, it removes the setting from the json.
This is not only wrong, but also unnecessary, since the settings editor already has a simple way to track modified settings and reset a setting to its default value:

I strongly think the current behavior is incorrect, because these two things are completely different when we think about user intention:

• explicitly wanting a value that happens to be the default
• accepting whatever the default is for that setting

An example of why I think this sort of thing is important:
https://money.cnn.com/2018/06/07/technology/facebook-public-post-error/index.html
It may be an extreme example, but you get the point.

This incorrect behavior is the sole reason I was still using the json to edit my settings, and it became more of a concern now that the new editor is the default.

The correct behavior should be:

• When setting the value explicilty, mark the setting as modified/overriden and keep the setting in the json, even if it happens to be equal to the default. The user wants the guarantee that the setting will have THAT value, and a way to remember that such value was explicitly chosen by them.
• When choosing "Reset Setting", remove the setting from the json, because the user wants to accept whatever the default is, even if it changes later. Mark the setting as not modified/overriden.

If possible, change the text and semantics of "modified" settings to "overriden" settings.

I agree that this is confusing. I think that supporting this for power users could also be confusing for newer users. Imagine if they click a checkbox on a bool setting to modify it, then click it again to "unmodify" it. Most people won't expect that action to have side effects, but it would have the side effect of writing the default value to the JSON.

I want to keep thinking about and discussing this, but I am also putting the experience for new users first in the UI.

[geekley]

Well, if a user checks and unchecks a setting, they will immediately notice that the setting now has a blue line, which wasn't there before. Even new users that don't know the exact meaning of the blue line will at least notice that something changed and didn't unchange.

If this wasn't intended, the first thing they will do (after possibly trying CTRL+Z) is look inside the gear icon. This is the intuitive thing to do, because its the only button related to the setting apart from the setting itself.

Even if they don't notice the change, or even if they don't get that the blue line means that there was some sort of change, I still believe strongly that the current behavior is not right. The side-effect of erasing a setting you had explicitly chosen before is more unexpected (even for experienced users) than the side-effect of adding and keeping a setting you explicitly just messed with.

Specially because there is also a separate reset button, so you wouldn't expect that explicitly setting something could also reset it.

[roblourens]

Even new users that don't know the exact meaning of the blue line will at least notice that something changed and didn't unchange

Yes but that's not a good thing, because they will be confused.

If this wasn't intended, the first thing they will do (after possibly trying CTRL+Z) is look inside the gear icon.

I disagree. I think many users will never notice or explore the context menu.

A checkbox is the simplest control in the world. It works the same on every form or in every settings page in every app, everywhere. If we change its behavior by introducing a mysterious third state, controlled by a different command in a hidden menu, we risk making users feel like they don't understand how a checkbox works. And if they don't understand even a checkbox, they will feel like they can't understand anything. This is why I want to proceed with caution.

[geekley]

Ok then, how about erasing the setting only if it wasn't already there before the settings tab was first open?
Then the current behaviour can be mantained, while people that already have a custom setting won't risk losing it unless they use the reset button.

[geekley]

My previous comment was for user settings.

In the specific case of this issue, (not being able to override the Workspace setting) this solution (an override checkbox before each setting) would solve it better, I think.

[roblourens]

@RedTailBullet had a good suggestion, that the default in the Workspace settings would match the configured value in the User settings. So here's how I interpret this:

• Starting clean with no configured settings
• Open User settings, see editor.insertSpaces is checked by default
• Open Workspace settings, editor.insertSpaces is checked by default
• Go back to User settings uncheck editor.insertSpaces. It gets the blue modified indicator
• Switch to workspace settings, find editor.insertSpaces, it appears unchecked by default, and doesn't have the modified indicator
• Click the checkbox, now it is checked and has the modified indicator

This is an interesting idea because it preserves "normal" checkbox behavior, it is transparent about the value at "this" scope (not taking the folder-level scope into account), and makes it easy and natural to override a value to the "default".

[RedTailBullet]

@RedTailBullet had a good suggestion, that the default in the Workspace settings would match the configured value in the User settings. So here's how I interpret this:

• Starting clean with no configured settings
• Open User settings, see editor.insertSpaces is checked by default
• Open Workspace settings, editor.insertSpaces is checked by default
• Go back to User settings uncheck editor.insertSpaces. It gets the blue modified indicator
• Switch to workspace settings, find editor.insertSpaces, it appears unchecked by default, and doesn't have the modified indicator
• Click the checkbox, now it is checked and has the modified indicator

This is an interesting idea because it preserves "normal" checkbox behavior, it is transparent about the value at "this" scope (not taking the folder-level scope into account), and makes it easy and natural to override a value to the "default".

Thanks roblourens! That's exactly what I mean.

[RedTailBullet]

One thing as well, the actual config.json for workspace setting should also be based on user settings.

For example:

• In user setting, the editor.insertSpaces is unchecked (which is not the default).
• In workspace setting, the editor.insertSpaces is checked again (which is the global default), and the json of the workspace setting actually have editor.insertSpace: true.

[SetTrend]

From the manual:

Workspace settings override user settings.

See: User and Workspace settings

[SetTrend]

Please consider that user settings differ from user to user, whereas workspace settings don't.

Adding a workspace setting tells the team that a particular setting is mandatory for the project, no matter what the actual user settings are.

So any workspace setting that's in the workspace settings settings.json file must be followed by VS Code, and must not be automatically removed by the visual Workspace Settings editor, even if that particular setting either meets the user setting or program default. A setting in the workspace settings settings.json file must only be removed when removing is explicitly desired.

Hence ...

1. Setting any value in the Workspace Settings editor should - regardless of the actual value - always be added to the corresponding workspace settings settings.json file.

2. I suggest to add a Remove button to each setting in Workspace Settings editor that's only visible next to each setting that's present in the corresponding settings.json file in the Workspace Settings editor. Clicking that button should remove that setting from the workspace settings settings.json file.

[lucasrcosta]

I agree with @SetTrend: "user settings differ from user to user, whereas workspace settings don't".
I'm having an issue with "Trim Trailing Whitespace". I like to used it in all my projects, but if you want to contribute in a project with some whitespaces and you save, a lot of lines have changed. Right now my only option is to disable it on the User settings, hope I don't forget to turn it on again...

[ZSkycat]

Setting the workspace to the default value does not override the user settings. This is a very confusing behavior.
When I use the UI settings, if I don't pay attention, I will break my workspace settings

The UI settings of the workspace are displayed as inherited values will be better.

[EskelCz]

I just ran into this nonsense. :( Workspace settings have to override user settings, at least for linters.

[esr360]

I'm also confused. My workspace settings should surely override my user settings?? Why wouldn't this be the expected behaviour?

[AlexandreDecan]

I got into this issue as well while testing the "remote - ssh" extension. On my laptop, I've a user setting that defines where to find linters in Python (e.g. path to flake8). On the remote machine, I would like to define this path to "flake8" for this workspace, but I can't because it's the default value assumed by vscode. I currently have no "direct way" (using the UI) to specify that for this specific workspace, I would like "flake8" (the default value in vscode) to override the value I put in my user settings.

[yhvicey]

I got into this issue as well while testing the "remote - ssh" extension. On my laptop, I've a user setting that defines where to find linters in Python (e.g. path to flake8). On the remote machine, I would like to define this path to "flake8" for this workspace, but I can't because it's the default value assumed by vscode. I currently have no "direct way" (using the UI) to specify that for this specific workspace, I would like "flake8" (the default value in vscode) to override the value I put in my user settings.

To workaround you can change the setting editor to split json mode by setting below two options:

  "workbench.settings.editor": "json",
  "workbench.settings.useSplitJSON": true,

Then you can override your settings in workspace tab manually:

This works for non-workspace folders as well.

[AlexandreDecan]

Thanks @yhvicey !

[rzhao271]

Starting from tomorrow's Insiders release, users should be able to add workspace settings that stay in the workspace file until manually reset.

The default values the workspace settings display in the event that they have also been modified in the user settings will still be the default values rather than the user values for now, though.

[rzhao271]

Looking above again, there's more demand than I thought to show inherited values.
I'll move this issue to the next milestone rather than close it early for verification.

[mind6]

If I set the User setting tab size to 3 (a non-default value), the Workspace setting shows 4 (the default value) in the UI, but behaves as if tab size is 3 in the editor.

My desire is to use 4 the default value for Workspace, but keep 3 in the User setting. The workaround is to manually put

{...
	"settings": {
		"editor.detectIndentation": false,
		"editor.tabSize": 4
...}

In the workspace settings files.

Is this caused by the same issue?

[jepperaskdk]

What's the status on this?
I would expect workspace settings to override user settings (how else can we enforce any settings for the team working on a codebase?). If you're worried about this being a breaking change, how about releasing it as an opt-in setting initially?

[rzhao271]

@jepperaskdk No updates—I've been working on other tasks. There are also two workarounds:

1. Run the command workbench.action.openWorkspaceSettingsFile to open the workspace settings file. You can then add settings you want the codebase to have to the JSON file.
2. In the Workspace tab of the Settings editor, you can change the value of the workspace setting to some other value, and then change it back. Once there is a blue bar to the left of the setting, it has been saved to the workspace settings file successfully and is overriding the user setting. When hovering over the setting, you might see a gear icon. Press on the gear and the Reset Setting option to remove the setting from the workspace settings file.

[ShadowLNC]

At the risk of being a "+1", I ran into this again due to microsoft/vscode-mypy#184 (I originally hit this in June 2021 with Pylint).

Workspace settings UI continued to show me it was set to useBundled even though my User settings are fromEnvironment (the latter causing the extension to error out due to the linked issue).

At least now I can change the setting to fromEnvironment and then back to useBundled now and it will persist, rather than having to edit the JSON - thanks! 😅