Profiles feature request: Ability to apply user settings across all profiles

[aaronsteers]

As mentioned also in: #15909 (comment)

The release of Profiles feature is exciting but I can't figure out how/if I can use this for "mode switching" in my own dev experience.

I am having a hard time making these work for the named application here (from the docs):

Since profiles are remembered per workspace, they are a great way to customize VS Code for a specific programming language.

I'm starting to hoping to use Profiles to keep my IDE more lean and focused - for instance one profile for Python development, one for Terraform development, and one for Data Analysis. But what I'm finding is that the isolation between profiles is a bit too strong in cases. Perfect example is my use of Code Spell Checker - I have built a usage pattern of always adding exceptions/additions to the default spell check dictionary to my user settings - these follow me everywhere. But now, if I correctly understand the behavior of Profiles feature, these settings won't follow me to other profiles.

Now with profiles, I think I'm going to end up repeating the same changes, and having to deal with drift across these profiles when there are some settings I just want to have permanent.

I don't know if we're going to get updates to Profiles feature that will allow some settings to follow us across profiles. The example above for the spell check dictionary, but also applies for extension settings like, ChatGPT, Live Share, etc. I think the common theme here is that certain settings and extensions are personal and some are modal.

Proposal

Application of two profiles

I think this basically requires two layers of profiles to be active at the same time:

• the personal profile: the "base" default/global/personal profile
• the modal profile: the "applied" profile like "Python", "Terraform", etc. - which are focused on what kind of work I'm trying to get done in the moment.

Handling global settings

Basically, there are certain plugins I'd like to treat as "global" or "personal" and those would ideally have these behaviors:

• Their settings should be maintained in my global user profile, and would not be duplicated for each of my "modal" profiles.
• When I export my profile to share with others, probably I am trying to export my modal profile settings, and not my personal/global ones.

Handling extension-managed writes when 2 profiles exist

I believe this algorithm is sensible:

1. Whenever setting a value {my-ext}.{my-setting}, first check if a same-named setting exists in the personal profile. If yes, update it there.
2. Else, if the same-named setting exists in the applied modal profile, then update it there.
3. Else, if the {my-ext} extension has any existing config in the modal profile, set the new setting there, adjacent to existing settings. (We presume the setting is modal until the user has moved it to their global profile.)
4. Else, if the {my-ext} extension has any existing config in the personal profile, set the new setting there, adjacent to existing settings.
5. Else, (the extension has no settings anywhere in either profile), write to the modal profile.

These, I think, are sensible default behaviors - specifically because:

• The action of a user "moving" a setting from the modal profile to their global profile would be remembered and honored next time the setting is updated.
• We have some preference for adjacency, keeping settings from the same plugin in the same profile unless there's a preference from the user to do otherwise.
• We assume most settings are going to live in the modal profile, again, unless the user tell us otherwise by moving them to their personal profile.
• This algorithm produces predictable "read" behaviors when personal settings have higher precedent than modal once.

Handling settings resolution ("read" behavior)

When reading settings, personal profile always has precedent. Modal profile has lower precedent.

Impact on "imported" profiles, or profiles gotten from other users

This behavior nicely keeps a user's own settings as overrides when importing community-created profiles.

E.g. If I import a "Python" profile from my community, I don't lose my custom Live Share settings upon import.

Rendering in VS Code Settings UI

This would have a 3-level interface. Instead of "User" meaning "Profile" in the screenshot below, there would be separate tabs for User | Profile | Workspace:

Since "User" has already come to mean "profile", the word "Personal" might work better: Personal | Profile | Workspace might be even more clear.

Better yet: naming the profile in the tab makes it super obvious what profile is applied and where setting values will be stored: Personal | 'Python' Profile | Workspace. This is nice because the answer to "which should I use" becomes much more intuitive.

Education

Probably, this is most simply communicated to users by distinguishing between "User Settings" or "Personal Settings" and "Profile Settings".

The algorithms for how settings are read and written can be more described concisely as:

When configuring an extension for the first time, VS Code writes settings to your active Profile. When you configure a User-level setting, or if you move a setting from the Profile to your User config, VS Code will remember this and treat the setting as a User-level config on future updates. If a setting exists at the User level and also in the Profile, the value from your personal User profile will have priority over the Profile setting.

This allows you to freely switch between your own profiles, as well as community-maintained profiles, without losing personal settings such as usernames, personal window styles, and other settings which you have set in your personal User config.

---

Is there an option to do something like this today? It is being considered for future development?

I checked the Profiles docs and could not find any mention of handling for profile overlays.

[the-exodus]

I came here to report the same issue, although from the direction I come from I feel it would make more sense to solve it by just applying the profile settings.json on top of the user settings.

So when switching to a profile it would combine the default settings with the user settings, as usual, and then just smack the profile/settings.json on top, before actually committing the settings-object to vscode.

In case a profile wants to revert a user setting to the default value I suppose the property could just be set to undefined in that json, in which case the settings "manager" would just grab the default value for it.

The reason I came here was terminal.integrated.fontFamily which I've now had to set in every profile I've created...

[sandy081]

/duplicate

#15909

[vscodenpa]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.

Happy Coding!

[aaronsteers]

@sandy081 - That issue doesn't mention the challenges with getting/setting values from multiple files. It seems that item (written pre-Profiles) assumes that we're importing/grafting a file's contents on top of the main one.

Would that presume that Profiles keep working how they do today, and the user would manually curate their own personal settings file(s)? Or would that proposal have a context for layering what we now call "Profiles" on top of each other? And is the scope of that issue expected to expand to include settings UI support as well?

For ref:

• Add ability to extend from other settings files #15909