subsets for settings editor

[bbannon]

Didn't find any duplicates, but it would take a month to search them all.

On the 'control comma' settings editor screen,
it would be nice if 'user', 'workspace' and 'project folder' were subsets.

The 'user' settings should be unique to me and my computer;

• my name and credentials
• my theme: (light | dark), font-face, font-size, screen reader, etc.
• where are composer, docker, php, etc. installed
  • and, by the way, ONE path for all extensions to use!
• other things that should NOT be committed to github | bitbucket | etc

The 'workspace' settings should be common things across all my projects;

• indent (space | tab) size
• 80 characters per line
• common vscode extensions: eslint, prettier, stylelint, etc.
• dev package.json

Then 'project folder' settings specific to each project;

• The ONLY things pushed to github repository
• eol
• trim whitespace
• character set (utf-8, latin, etc)
• Code Spell Check 'project-words.txt'
• The fool boss wants tab indents and no lines longer than 65 characters.
• composer for devs
• composer for end users
• package.json for production server
• specific vscode extensions for devs
• which file types should minimize to 'distro' folder

There may be some overlaps between workspace and project settings.

When I init a new project, ask which 'workspace.config' files to copy to 'project/src/', by checkbox.
Perhaps, ask which workspace files to copy to 'project/distro' folder. Or setup '.config' for these 2?

In the settings editor, instead of going through settings 3 times for user, workspace and project, have checkbox by EACH item - user, workspace, open project; that determines where settings are saved all at once. Things unique to 'user' should not allow checkboxes for workspace or project.
Maybe radio buttons would be better; workspace, open project , both?

I think I'll end there, before this becomes a novel.

[rzhao271]

This is an interesting feature request because it's suggesting a massive change relative to how the Settings editor currently works. For example, workspace settings in the Settings editor aren't common settings across all projects, but are settings that apply to the currently open workspace. With the way the Settings editor currently works, settings configured under the Workspace tab will always be committed to GitHub if you don't .gitignore the .vscode/settings.json file, whereas settings configured under the User tab will never be committed with your projects.

Check out https://code.visualstudio.com/docs/getstarted/settings and https://code.visualstudio.com/docs/getstarted/settings#_settings-precedence for more details on how the settings are arranged within the Settings editor, and how setting values in a scope can override setting values in another scope.

Also check out https://code.visualstudio.com/docs/editor/workspaces to learn more about what "workspace" means in VS Code. The "project folder" setting tab with the dropdown only becomes available when you open a multi-root workspace, whereas the "Workspace" Settings editor tab becomes available when you open any folder.

Let me know if you'd like more info on the Settings editor or have more suggestions for it.

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[bbannon]

My computer has been in the shop since I posted this. Just got it back.

My suggestion is basically, in the 'control comma' settings editor, if I select something for user settings.json it should not even show up in either workspace or project folder settings screens.

I participate in several projects. I have them all in a 'projects' folder, each in it's own sub folder. My 'workspace' settings.json is common to all of them, in the 'projects' folder. In each project's .vscode/ sub folder, are the settings specific to that project. There is a lot of overlap, but each project is a little different.

[rzhao271]

if I select something for user settings.json it should not even show up in either workspace or project folder settings screens.

Isn't this already the case? If you configure a setting under the User tab, it does not show up under the workspace or folder settings.json files.

It is also by design that if you configure a setting under the User tab, the setting still shows up as an entry under other tabs. If I configure files.autosave in the User tab, and then configure it to a different value in the Workspace tab, then the Workspace value will take effect for that workspace.

Reopening for further discussion.

[bbannon]

It wasn't already the case. Project <name>/.vscode/settings.json was asking "where is composer/docker/php installed"? For example. Among other things. I had already set those in user/settings.json. Maybe it was an extension that was asking? Again. Several extensions have duplicate entries like that.

…

On Wed, Nov 15, 2023 at 12:10 PM Raymond Zhao ***@***.***> wrote: if I select something for user settings.json it should not even show up in either workspace or project folder settings screens. Isn't this already the case? If you configure a setting under the User tab, it does not show up under the workspace or folder settings.json files. It is also by design that if you configure a setting under the User tab, the setting still shows up as an entry under other scopes. If I configure files.autosave in the User tab, and then configure it to a different value in the Workspace tab, then the Workspace value will take effect for that workspace. Reopening for further discussion. — Reply to this email directly, view it on GitHub <#197415 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHJ7GLQL3PSA35YZYUMS5KLYEUHQ3AVCNFSM6AAAAAA65BSUP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTGEYDONBRGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rzhao271]

Could you give some example setting IDs?
Duplicate entries being required sounds like an issue with those extensions or settings.

[no-identd]

While I can't speak on the symptom(s) which prompted this, I can speak on the proposed solution:
from a sysadmin and/or CompSci and/or poweruser[¹] perspective, the hierarchy of settings seems incomplete.

• It's incomplete from a CompSci perspective because it, informally speaking doesn't use a sufficiently generic design covering trivial implementability of[≈extensibility to] all n layers/permutations of user & computer (non-)locality & scopes
• from a Windows Sysadmin perspective,
  it doesn't enable mandatory configurations enforcible via group policies, by which I in this case DON'T mean Administrative Templates but rather configuration files placeable( via Group Policy Preferences) in folders with ACLs prohibiting modification by non-Administrators. Cf.
  [¹ it may seem contradictory to speak of a distinction between users and powerusers in the context of configuration UX & file layout design, however, please note: in case one thinks that, one probably already belongs to the category of powerusers. Most developers nowadays actually fall in the category of users, not powerusers.)
  • cf. https://learn.microsoft.com/en-us/windows/win32/shell/manage (refers to Windows 2000 but prerequisite knowledge to understand…) & https://learn.microsoft.com/en-us/windows/win32/shell/known-folders.
  • (implicit in the design of Windows) scopes consist here (but are subject to overriding by Group Policy Preferences[≠Administrative Templates]):
    • Computer
      • "Public" (read & writable by ALL users. This scope suffers from underscoping, neither distinguishing between network & local users, nor between authenticated & unauthenticated users, in SOME scenarios)
      • "ProgramData" (this scope suffers from both scope pseudo-pollution AND quasi-pollution made worse by lack of sufficient documentation, albeit one can, with sufficient application of frustration driven obsessive willpower, deduct the almost certainly actual intent from comparing statements from the documentation with the behavior of both the actual NTFS ACLs as well as with the behavior of folder redirection compatibility shims: the creation of data is possible for all users here, however, only the data creator can then subsequently modify the data. Data typically gets created by installers, which run with UAC elevation thus restricting rights to the "Administrators" group implicitly, unless the application installer decides otherwise. Perhaps if the Shell team had realized the existence of the NT Principal OWNER RIGHTS, and not just the existence of CREATOR OWNER, which aren't the same thing, we'd have gotten a better design, but eh, good enough most of the time)
    • User
      • User Roaming
      • User LocalLow
      • User Local
  • Hosting Application
    • please see https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles?view=powershell-7.3#profile-types-and-locations for an example of how this should get implicitly handled by/via the above. Probably not relevant for VSCode per se, but possibly for it's underlying editor component.
• for the Linux sysadmin perspective, please find the latest flamewars over https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard & https://en.wikipedia.org/wiki/Freedesktop.org#Base_Directory_Specification within mailing list servers & Newsgroups of your choice
• can't help with the MacOS X Sysadmin perspective
• deduction of the poweruser perspective from the above is left as an exercise to the reader

And I probably forgot some more stuff on the windows perspective, like CommonProgramData, it's sibling inside user profiles, and RDS/TS Roaming Profiles vs non-RDS/TS Roaming Profiles.

Should VSCode cover config layering via/for all of the above? Probably not. Should it be capable of some subset larger than what it can now? Almost certainly. Which exactly? idk lol it depends

Edit:
Sorry for the broken markdown, seems my github mobile Client has some issues. I'll fix it later.

[bbannon]

I got my computer back completely wiped, it's going to take a couple of days to set up everything.

I think the extensions for composer and docker, among others, asked where they were installed. And composer asked where php is installed. Then put entries that duplicated in workspace what I set in user/settings.json.

Extensions should not even ask that kind of thing. They should presume that the program is installed and path set up. If it can't find it, then give an error message.

[vscodenpa]

This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the marketplace for VS Code. See also our issue reporting guidelines. If you don't know which extension is causing the problem, you can run Help: Start extension bisect from the command palette (F1) to help identify the problem extension.

Happy Coding!