-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Settings editor not showing inherited values in workspace scope #58038
Comments
(Experimental duplicate detection) |
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. |
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. |
I thought it would be less confusing to show always show the default unless a setting is modified in that scope. |
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? |
From #58901
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. |
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. |
Yes but that's not a good thing, because they will be confused.
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. |
Ok then, how about erasing the setting only if it wasn't already there before the settings tab was first open? |
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. |
@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:
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. |
One thing as well, the actual config.json for workspace setting should also be based on user settings. For example:
|
From the manual:
|
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 Hence ...
|
I agree with @SetTrend: "user settings differ from user to user, whereas workspace settings don't". |
Setting the workspace to the default value does not override the user settings. This is a very confusing behavior. The UI settings of the workspace are displayed as inherited values will be better. |
I just ran into this nonsense. :( Workspace settings have to override user settings, at least for linters. |
I'm also confused. My workspace settings should surely override my user settings?? Why wouldn't this be the expected behaviour? |
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. |
Thanks @yhvicey ! |
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
In the workspace settings files. Is this caused by the same issue? |
What's the status on this? |
@jepperaskdk No updates—I've been working on other tasks. There are also two workarounds:
|
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 At least now I can change the setting to |
This issue still exists for remote scope. |
Steps to Reproduce:
Set some value to true in your user settings, like editor.formatOnSave:
Open settings editor, switch to Workspace Settings, you will see the item is unchecked but showed (modified by user):
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
The text was updated successfully, but these errors were encountered: