Vscode: New settings editor cannot override value in workspace settings

[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[bot]]

(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 !

[roblourens]

You don't have to use the deprecated "split" json editor for this. Use the command "Open Settings (JSON)" or the button in the corner of the settings GUI that opens the backing JSON file.

[richard-biarri]

Can't override a setting to turn off format-on-save in Workspace settings if it's set to on in User settings. Blue "overrides User settings" line appears when you check the box (which is wrong because the override is the same as the User setting) but it disappears when you uncheck the box, which is now a different setting from the User setting.

If the Workspace is inheriting a User setting then that setting should be displayed in the Workspace settings unless it's overridden. A checked User setting should appear checked in Workspace, and when the unchecked, it should have the blue line indicating that it differs.

[sebastian-fredriksson-bernholtz]

@roblourens Don't you think it's more confusing to show a value that doesn't apply in Workspace Settings (UI) than to explicitly setting a value to the same as default? Considering that Workspace Settings are supposed to override all other settings?

I haven't looked at the code but it seems that:

1. Workspace Settings (UI) will show the default value unless specifically set in Workspace Settings (JSON). Regardless of whether the User Settings are overriding the Default Settings.
2. Workspace Settings (UI) will also only write to Workspace Settings (JSON) if the value is different from the default value. It will delete the setting from Workspace Settings (JSON) if it is the same as Default.

The first issue is handled to some degree by (Modified in: User). Considering Workspace Settings are supposed to override User Settings it's not very intuitive that being modified in User Settings means it overrides the setting shown in Workspace Settings (UI). It would be clearer if it showed (Overridden by: User). Even better would be to show the actual value applied to the workspace and where it's been set. As in (Set in: User)/(Set in: Default). For text input settings the applied value could be set as placeholder rather than value.

I think the second issue is worse. Why make it make it impossible to make the workspace explicitly use the default setting through Workspace Settings (UI)? The only benefit with the current behaviour seems to be that it is possible to disable the Workspace Setting so that the User Setting is applied.

[k3n]

This violates the principle of least surprise IMHO.

[esr360]

How can I keep my personal projects at 2 space tabs whilst also allowing work projects to have 4 space tabs?

[andrewmiroshnichenko]

I just ran into this issue. From my point of view, on https://code.visualstudio.com/docs/getstarted/settings text

Workspace settings override user settings.

should be removed, because it is simply not true.

Can someone give approximate estimate for this issue resolution?

[heshuimu]

+1

[mattgaspar]

Currently to force the default value to override a user setting for a workspace you need to:

1. Click the gear icon next to the setting
2. Click "Copy Setting as JSON"
3. Open the workspace's settings.json file
4. Paste the default setting (that was copied in step 2) between the brackets

Proposed Solution
Add an additional option to the gear menu that says something like "Force default value" or have clickable text next to the setting (if the default is selected) that says "Force default" or "Override user setting".
Clicking any of these would be a shortcut to doing the manual steps above.
_I think this should only be added to the workspace tab, it might be confusing on the User tab since it wouldn't actually override a workspace setting._

Also it would be helpful to show the actual active setting.
How about if the active value for a setting does not equal the value you are looking at, have a message like _Active value is currently: onFocusChange_ appear next to or under the setting.
_This would be for both the User and Workspace tabs._

[1valdis]

I agree, this is confusing. Please make workspace overriding more user-friendly. I was just trying to modify workspace settings and wondering why this doesn't work at all, and googled to find this issue.

[Drixled]

Is there any ETA for this? Even when I paste the JSON on my settings.json like @mattgaspar said the change does not override because the hierarchy rule is Workspace > User.