Profiles: Extend from Default Profile

sandy081 commented 2 years ago

Allow to configure settings across profiles.

One idea we are considering is to allow users to choose between following options while creating a profile:

Extend from Default Profile
Diverge from Default Profile

When chosen to extend, settings from default profile are applied unless user overrides them in the profile.

GongT commented 2 years ago

need something like:

{
    "setting.item": { "$linkWith": "default" }
}

or

{
    "profile.link": [
        {"source": "default", "keys": ["item", "item2"]}
    ]
}

I also need keybindings never change between profiles. or this feature is not usable for me.

dimateos commented 1 year ago

Exaclty, I was expecting settings profiles to allow specifying what is to be replaced from default, something like what is done in settings sync:

Basically I need keybinds and settings persistent across profiles. Otherwise when I add new ones/update in the default profile I have to recreate profiles or edit the exported file with a diff and reimport... Also note how there are conditional clauses for hotkeys (e.g. editorTextFocus && editorLangId == 'markdown') that you can use to differentiate per language. So there is no need for profiles per language here, which is one of the main uses of setting profiles. I believe there are also similar options for settings per language, but I think that this is less used.

Anyway I only plan to use setting profiles for enabling extensions per language/work-place, and I think am not alone (multiple extensions target this specific case). The fact that it enforces persistent settings and keybinds prevents me from using it.

Your proposed features to just extend/diverge from default could work, although then maybe e.g. there is no way to add new extensions while disabling others?

Lamarcke commented 1 year ago

This would indeed be a really great option.

Often, when i need to change a setting for something native or for a extension i use in all profiles (like GItlens) i need to copy and paste in every profile. (Although knowing where the profiles' settings.json are stored make this easier). This would also apply to keybinds.

kozer7 commented 1 year ago

This is the idea of my profile settings. I use many tech stack and I like to try new things so I change my extensions very much. But I would love to have layered or stacked profiles not just extending from one. Let me give you a example.

One of the programming languages I mainly use is Java. I use diffrent tools(extensions) and let me group these like these: +Java: ++ Editor Settings, Key Bindings & Java related extensions like Spring Framework, Maven, Gradle, Test Extension and more. ++ (Optional) Container Extensions ++ (Optional) Kubernetes Extensions ++ (Optional) Git related extensions ++ (Optional) Xml, Yaml, Json etc. related extensions. ++ (Optional) NoSQL data management extensions ++ (Optional) SQL data management extensions

and goes on. The other language I mainly use is python and this is the tools I generally use.

+Python: ++ Editor settings, formatter, virtual env. manager and test extensions ++ (Optional) Container Extensions ++ (Optional) Kubernetes Extensions ++ (Optional) Git related extensions ++ (Optional) Xml, Yaml, Json etc. related extensions. ++ (Optional) NoSQL data management extensions ++ (Optional) SQL data management extensions

Apart from these I try to play with Flutter, Angular or React frontend tech stacks:) Ok, I dont use them mainly but wanted to have an opinon about them. but still use them every now and then.

So what I wanted to do is, activating each required profile for the project. I mean one python application is running on containers and I have to activate related extension but one project is not using any container mechanism. I dont want to deactivate them manually and re-open. Same as using sql or nosql related extensions.

This way I can update a profile like adding GitLens to git profile. And all projects in which git profile active will have the Gitlens.

cweagans commented 1 year ago

For me, this is really the only thing that's missing from the settings profile functionality as it exists currently. I was using https://marketplace.visualstudio.com/items?itemName=cyberbiont.vscode-profiles for a while. My base profile has only a couple of plugins (vscodevim, editorconfig, markdown preview mermaid support, and the Nord theme) and a fair amount of configuration that's standard across every tech stack I work on (font, UI, window settings, etc).

In the secondary profiles that extend from the base profile, I intend to add language-specific extensions and configuration. I would love to not have all of my base configuration duplicated in the secondary profiles. I would like to not update my font in a bunch of different places if avoidable.

cweagans commented 1 year ago

Alternatively, instead of having separate config files for different profiles, having profile-specific sections in the main config would work well:

{
    "editor.fontSize": 15,
    "editor.lineHeight": 1.9,
    "[profile:screencast]": {
        "editor.fontSize": 20
    }
}

frypf commented 1 year ago

It would definitely be useful to have the option some sort of inheritance from other profile(s) - or even better a way of specifying profile-specific overrides similar to the "[someLanguageName]": {...} syntax already available for language-specific settings.

Basically I need keybinds and settings persistent across profiles.

Anyway I only plan to use setting profiles for enabling extensions per language/work-place, and I think am not alone (multiple extensions target this specific case). The fact that it enforces persistent settings and keybinds prevents me from using it.

This is my main use case as well - I already have any language-specific keybindings set up as I want them using "when": editorLangId == 'someLanguageName', and most of my language-specific settings are written directly into the global settings.json, but profiles seem the only way to specify which extensions I want to enable or disable for a given project without relying on clicking the UI.

Where my current approach falls down for me is that sometimes I might be momentarily working on a different language within eg. a Python or Swift project or whatever. This is where I tend to use workspace-scoped settings, so I had hoped profiles would make the process of applying the same settings overrides across a bunch of different workspaces redundant. However, frustratingly, instead I now have to remember to update new keybindings or altered global settings across a bunch of different profile-scoped keybindings.json and settings.json. Admittedly there's far fewer profiles than workspaces on my machine, but unfortunately it's not even obvious at a glance which of these files apply to which specific profile.

(Although knowing where the profiles' settings.json are stored make this easier).

I was only able to discern this by using revealFileInOS for the settings or keybindings json from within a profile. Is there any possibility of giving the individual profile directories within ~/Library/Application Support/Code/User/profiles more intuitive / discernible names?

For now I'm experimenting with hardlinking my keybindings.json and settings.json files into each individual profile when I set it up. I did originally try with symlinks - but any updates I made from within my Default profile where only reflected in other profiles after resaving the json from within that profile, whereas updating a setting or keybinding from within a profile was instantly reflected back in Default.

eccentricOrange commented 1 year ago

Coming from #175427, I really need some core settings like files.autoSave to be consistent.

frypf commented 1 year ago

In addition to my previous points, I've found that currently when within a profile's settings.json, any settings marked as 'application-scoped' are dimmed and show the following message when hovered: This setting has an application scope and can be set only in the user settings file. These settings still seem to take effect, but it's confusing to say the least.

The UI could definitely be improved for this, and more generally for setting up profiles overall. The checkboxes are intuitive when it comes to specifying which extensions are enabled / disabled. However, with everything else (settings, keybindings etc) it's not obvious what the differences between checked / unchecked might be. I had assumed that leaving something unchecked would inherit whatever I was using within my default profile, and it was only after finding this thread that my expectations were actually clarified.

As we've come to realise, checked means that the entire file is copied wholesale to the new profile and any changes made subsequently to that file diverge from the base, while unchecked means that VSCode generates an empty / default file for those sections. I've also since realised that user tasks and snippets need to be part of the proposed inheritance model as well as settings and keybindings.

The checkbox-based 'Show Contents' view in the sidebar which allows us to tailor and export a new profile should be presented whenever I invoke 'Create profile'. This view would be of far more use if it actually took effect on a profile in real-time rather than just the generated exported profile.

From my POV at least, the default assumption on on VSCode's part should be that unless I've checked something, I just to want the new profile to use whatever I've already set up and am using successfully. There needs to be better indication of what the checkboxes mean (for everything other than extensions), possibly using a drop-down or similar with the options stated within the OP:

Extend from Default Profile Diverge from Default Profile

(and possibly additional options such as Generate empty for those who do want an entirely separate uninherited version).

If the proposed inheritance model is adopted, will it still be possible to open the pertinent .json files for both global and profile-scoped settings etc. via a command or keybinding, as is currently the case with workspace-scoped settings?

mircmo commented 1 year ago

I also think that there needs to be a profile hierarchy of some kind for the profile feature to become really usable. I mean just alone for key bindings, these are rarely profile specific in my experience.

The best approach in my opinion would be something like what's already mentioned in this issue: https://github.com/microsoft/vscode/issues/173473 This solution would be really flexible and is also a quite widespread approach on how to handle different configs (e.g. tsconfigs, eslint configs or even the user/workspace settings in VS Code). The behaviour would be just like with workspace settings. The workspace settings get added on top of the user settings or in this case, profile settings get added on top of another profiles settings. In the user/workspace settings scenario the inheritance is implicit but for profiles it would have to be explicit with like a "extends": "default-profile" key in the json file. I think it would also make sense to allow multiple levels of inheritance. A limit probably wouldn't hurt, but more than one level should be possible. Consider this scenario:

Base (includes my key bindings, theme, gitlens extension and stuff like this)
- JS Web Base (eslint, scss extensions and so on)
- Nextjs Tailwind (nextjs snippets, tailwind, prisma...)
- Angular (angular language server, snippets...)
- Dotnet (C# language support, Azure Tools...)

You could make this work with one level of inheritance, either by having some extensions and configs duplicate across profiles or by "merging" two profiles to have e.g. react and angular extensions in the same profile, but in my opinion its cleaner to just allow this structure to begin with. Also I can think of a couple improvements that could be made in the future that would benefit from having smaller more specific profiles.

Some problems I can see so far with this approach are the UI State and Extensions part of the profile. While inheriting like described above makes perfect sense for the Settings, Keyboard Shortcuts, Tasks and Snippets its probably a little bit trickier with the other two. I would have to take a closer look at how the ui state json works since I currently haven't got a clue. The extensions part is also a little bit unclear to me. What do those checkboxes in the profile UI do? Do they disable the extensions? Do they remove them from the profile? Do they simply modify the result of the Export button? Either way would there probably be something to rethink...

Another thing that might me improved with this, is the relation of user settings and profiles. Since no documentation on the profiles feature exists as of yet and I've not bothered to dive into the source code, I'm not sure how this even works at the moment. If profile inheritance would be implemented you could arguably replace the user settings with a default profile. But that would probably be a thing to think through if someone decides, this approach is the way to go.

Anyway, I would love to give this a shot, however there are still some uncertainties. I would like really like to hear some thoughts on this. Does anyone see some flaws with this approach or has a better one?

If enough people think this approach is a good idea I'll try to implement something :)

RoyalFoxy commented 1 year ago

@mircmo I think your approach is a good implementation for having multiple profiles and I agree when you say that without some kind of inheritence the profile feature as is is somewhat annoying and frustrating to use. I myself find me deleting and adding config accross multiple profiles and it's always a big pain.

Regarding the extensions, I was also somewhat confused at how the extensions worked and it's weird... The last time I tested it (January build of the normal vscode) the extension tick boxes in the export profile view didn't do anything, even if I unticked all, the profile would still include all profiles... The solution in the end was to uninstall the extensions inside a profile itself which worked.

I can't help with the uistate much as I think it's not something you're supposed to edit yourself as there isn't a command in the palette to open the uistate file. I think it would be a good idea tho to have an option in the settings json kinda like the "extends" option you discussed but for the uistate. I see myself rarely changing the uistate on profiles however there are some cases like when you're using a db extensions for mongodb which you don't use in any other profile and you want it visible and to implement something like that needs some more thinking...

Just to clarify tho when you said "like with workspace settings" you meant that the profile settings json would have property depending on if you're creating an empty profile or an inherited one being the "extends" property and a few more properties which are specific to that profile like a special formatter or language specific settings that you can't include in the default profile and it would result in just a few lines (depending on the use cases) or am I wrong about that?

At least the way I understood your approach is the way to go and it's roughly what I thought about aswell.

mircmo commented 1 year ago

@RoyalFoxy Yes, I think we mean the same thing. However it's a little bit more complex because there isn't just a profile file where the additional config for that specific profile is stored, there are several files for all the different configs (settings.json, tasks.json, snippets...) in a profile folder. But I was thinking about that aswell, if I should move that directly to the profile file, but for backward compatibility reasons I probably won't do that. My current approach is basically:

Update the behaviour of creating a new profile so you can choose an existing one to extend from
Add a new optional "extends" key to the profile config, which is automatically set when you choose one to extend from
Add logic for when changing your profile, a "computed" settings file gets generated which essentially "merges" your configs based on the extends property, so VS Code doesn't have to compute them every time it wants to read them. This is almost necessary if I want to allow multiple levels of nesting

RoyalFoxy commented 1 year ago

@mircmo I just thought about an edge case for developers which use multiple technologies in one project. There's a similiar technology to electron which is tauri and it uses rust and a javascript frontend e.g. react or svelte (up to you to decide) and it would be cool to have the extends property also accept a list of profiles to inherit from as for tauri again I would basically have to switch back and forth between my rust and my react profile or combine them into one but that would get annoying again as I'd have to take settings from one profile and copy it to another etc.. I thought that the list passed to the extends property could work in a way where the first item had the highest priority and would overrite all other profiles settings which want to change the same thing

profile A

{
  "editor.fontFamily": "Monocraft Nerd Font",
  "editor.fontLigatures": true,
  "editor.fontSize": 20,
  "editor.lineHeight": 20
}

profile B

{
  "editor.fontFamily": "Consolas Nerd Font",
  "editor.fontLigatures": false,
  "editor.fontSize": 22,
  "editor.insertSpaces": true
}

profile C

{
  "extends": ["profile A", "profile B"],
  "editor.fontSize": 18
  "terminal.integrated.fontSize": 20,
}

Profile C in this case would end up looking like this

{
  "editor.fontFamily": "Monocraft Nerd Font", // Profile A overriden
  "editor.fontLigatures": true,               // Profile A overriden
  "editor.fontSize": 18,                      // Profile C overriden
  "editor.lineHeight": 20,                    // Profile A exclusive
  "editor.insertSpaces": true,                // Profile B exclusive
  "terminal.integrated.fontSize": 20          // Profile C exclusive
}

This would be extremely helpful for cases like tauri but also other cases like a backend and frontend like java spring boot with vue or any other framework/library combination that doesn't use the same technologies and you already have two profiles which you could combine.

I don't think this would add a lot of complexity.

mircmo commented 1 year ago

@RoyalFoxy Hmm yes, this thought had also crossed my mind. I agree from a technical standpoint, at least if my current approach works as intended, this would be really simple to implement in addition to that. However the dialog to choose which profile to extend from now would have to be multiple choice and more importantly would now have to somehow allow for you to choose an order. For this I don't have a good idea yet...

RoyalFoxy commented 1 year ago

I thought about two ways of implementing a dialog

First one would be displaying all profiles in order, when you tick one it moves up and gets a handle added to it, if you add a second one the same happens and so on. Now you can move the profiles into ordery top most being the one with highest priority and you can move them with the handle.

Second one is basically moving the order to a second dialog. First you select all the profiles you want to inherit from, then click next and in the second dialog you arrange them into order.

RoyalFoxy commented 1 year ago

Hello @mircmo, what's the progress so far?

mircmo commented 1 year ago

@RoyalFoxy I started with something last week, but its more complicated than i anticipated. I will continue when I find time, which will be mostly on weekends due to my job. I wouldn't expect a solution that soon because of the complexity and the amount of time I can reasonably invest. However if you (or someone else for that matter) would like to help in any way, that would speed up the process a lot, because solving problems together is always a lot more fun :) Then we could take a look at what I found out so far and how to go on from there using a different medium than these issue comments (eg. Discord, Teams...)

brettcannon commented 1 year ago

If this were implemented it would probably take care of https://github.com/microsoft/vscode/issues/176813 since you could use the default profile as your traditional "user" settings and then have all other profiles inherit from it (when that's what you wanted).

starball5 commented 1 year ago

Related Stack Overflow questions:

aaronsteers commented 1 year ago

If this were implemented it would probably take care of #176813 since you could use the default profile as your traditional "user" settings and then have all other profiles inherit from it (when that's what you wanted).

@brettcannon, I'm the author of #176813:

176813

and I agree. I'd be happy with having a "Default" profile as proposed here, which is merged with an applied modal profile, as a solution to my issue.

Without this, I can't really see myself using the Profiles feature day-to-day. More rationale on why in the above. (Essentially boils down to too many personal settings that I want to keep DRY.)

Nemesis19 commented 1 year ago

I agree with the spirit of the request. The problem is more simple than expected.

If I have basic configurations like editor font size, default formatters, UI personalizations that I want to keep consistent for every profile I can:

configure my default profile with basic settings
create any profile that extends the default
make my new profile customized with new settings just for the profile itself

the tsconfig.json example is a perfect representation of the solution.

It's just a matter of a "extends" key in the settings.json file...🤷‍♂️

dimateos commented 1 year ago

Keep in mind that profiles are not just settings.json, they currently pack all kinds of user configurations (hotkeys, extensions, snippets, tasks...), this makes them a bit more complex to handle. In my case, I'm interested in using Profiles to enable extension per workspace/language and I'd be fine if I could just ignore the settings.json packed in the profile (e.g. you can already configure settings per language).

There are some extensions in the market that target these cases separatedly, but improving Profiles to support all in an optimal and coherent manner seems the way to go. Currently, I also don't see myself using them day-to-day without the ability to extend a "default" profile. Having to maintain settings/hotkeys per profile it's literally a no-go for me, makes them only useful for an initial workspace setup which is sad given its great potential.

Probably limiting the additional profile to "extend" keys is okay for an initial implementation, but I think we can do better and "update" existing settings too. That's been proposed here and is already working perfeclty with Workspace settings replacing User ones. I guess that the hardest part is managing the extensions which are not simple jsons. Profiles already do a good job storing a pointer to a unique installation and remembering the enabled state.

I would like to add that, as of now, you can select what to import/export from a profile but only at the time of import/export, later you have to manually update settings or reimport... Somehow extending this behavior to be a dynamic setting for the profile would allow for a global settings/hotkeys/etc shared across profiles. It's not extending settings.json but could be a start and later also use the same UI but with a tri-state checkbox or something.

RoyalFoxy commented 1 year ago

@dimateos Well all json files can be easily extended with destructuring from both objects and then combining them in a new object where the profile you want to have priority goes more right in the implementation

const a = {
  "editor.fontFamily": "Monocraft Nerd Font",
  "editor.fontLigatures": true,
  "editor.fontSize": 20,
  "editor.lineHeight": 20
}

const b = {
  "editor.fontFamily": "Consolas Nerd Font",
  "editor.fontLigatures": false,
  "editor.fontSize": 22,
  "editor.insertSpaces": true
}

const c = {
  "extends": ["profile A", "profile B"],
  "editor.fontSize": 18
  "terminal.integrated.fontSize": 20,
}

const combinedSettings = { ...a, ...b, ...c }

and for the extensions its also not as hard as it seems as the extensions for a profile are saved in an extensions.json and for the default "profile" there's a lastSyncedextension.json file in the sync directory which contains the last synced extensions. Last part isn't optimal thought as it requires the user to use settings sync which may not be active so there should be a different implementation for a final pr but for testing purposes it's fine imho.

The only real difficult part I ran into when I tried making a smallish extension mainly for settings.json to be combined is that I couldn't find a proper dynamic way of setting settings on the fly without modifying the settings.json of a profile. It would be easily possible to just update the settings json of a profile BUT that's not really a good implementation as you'd have all your settings in every profile and the idea was to only have settings you want changed for that profile in the settings.json so you can easily manage and see what's managed by the profile and what's extended from a different profile.

There are ways to change settings in memory but it would be very performance intensive to change them every session + they wouldn't apply until the code merging the settings would be executed etc.. I personally think there needs to be a different foundation first with which you can easily modify the settings, extensions, keybindings etc. first before this can be properly implemented. I thought of a somekind of some files which basically act as a file you dont change as it's overwritten when you change profiles. Lets say you switch from Profile A to B then that mentioned file would be overwritten in the parts where B is different from A and that file would ALWAYS be used as the settings that are used essentially. I hope this makes sense sofar? And I think there probably already is a function somewhere that allows you to "choose" what files to consume as the settings and you'd basically change the call to reference that generated file and it would get regenerated if you change settings of your current profile or change profiles.

This already goes a lil into implementation details but I mainly also just wanna share what I thought of in the past days and what I think would be a good way to take to actually make this work!

EDIT: I checked and there's a .vscode(-insiders) folder in your home directory on unix machines which contains an extensions folder which then contains an extensions.json which has the same structure as the ones of the profiles.

mikestopcontinues commented 1 year ago

It looks like this is on the roadmap for this month. Any news on implementation or timeline?

RoyalFoxy commented 1 year ago

@mikestopcontinues the iteration plan for june has this ticket inside so it should be out by end of month depending on if they manage to develop it. Last month an investigation iirc of this ticket was put into the iteration plan.

This month:

sandy081 commented 1 year ago

After going through all related issues and comments, I observed that the most wanted use case is ability to have a profile that can use customisations from the default profile for specific data. For example:

A profile that uses keyboard shortcuts from the default profile.
A profile with only extensions customisations (extensions, UI state) and use default profile for the rest of the customisations (settings, keyboard shortcuts, snippets, tasks).

Here is the UX proposal how this will be supported. There will be an action Create New Profile... that will show following picker.

This will create a profile that uses keyboard shortcuts from the default profile. All other customisations (settings, extensions...) are scoped to the created profile.

Please note that when you chose to use default profile for specific data customisations then they are read and applied from default profile only. Overriding these customisations at profile level is not supported. For example in the above profile, any keyboard shortcut customisations are read and applied in default profile. You cannot customise keyboard shortcuts scoped to this profile. This is true for all data that is using default profile as fallback.

In addition to this, I am also planning to support following use cases

Ability to install an extension across all profiles - https://github.com/microsoft/vscode/issues/157492
Ability to have a setting applied across all profiles - https://github.com/microsoft/vscode/issues/176813#issuecomment-1497538441

PS: If you are looking for settings hierarchies, I would suggest to subscribe to Add ability to extend from other settings files #15909

eccentricOrange commented 1 year ago

@sandy081 I would like to make a suggestion here, borrowing from the example of settings in the editor.

There are three kinds of settings I've noticed: User, Workspace, and Remote. If I don't create an entry for a workspace setting, it is used according to the User setting.

Could you create something like this for profiles? I.e., a profile saves only the modifications/diffs from default, instead of copying completely.

I think this will cover a majority of use cases, and also presents a mental model long time users are familiar with.

carlocardella commented 1 year ago

@sandy081, I am late to this discussion but if I understand the proposal correctly, I see two problems:

I can use Default as base for NewProfile without including its settings: in this case I cannot customize a setting for NewProfile only, I will have to rely on whatever I am inheriting from Default, correct? If I change a setting in Default, NewProfile will be affected too.
If I use Default as fase for NewProfile including its settings and later update Default, I will have to manually replicate the change to NewProfile, correct?

This assumes NewProfile uses all or nothing customizations from Default: all (or no) extensions, all (or no) settings, keybindings etc. True inheritance (as we have for User, Workspace and Folder settings) is how I would see this really useful

mikestopcontinues commented 1 year ago

I'll second the issues here. I want a deep-merge of settings, more akin to the extends proposal. Child profiles should be able to override parent config in the same way that workspace and language overrides do, except applied to all settings categories.

sandy081 commented 1 year ago

Thanks for your feedback. I understand your use cases/requirements for settings inheritance/hierarchy. With suggested proposal, it does not mean that hierarchy in settings will not be supported.

Here is our thought process behind the proposal:

We want Profiles to remain flat. Since a Profile is a collection of different data - settings, keybindings, extensions, tasks, snippets and UI state, supporting hierarchy for a profile implies supporting hierarchy for all this data. The cost (Design, UX, Implementation) of implementing it is not worth because most of the data has no need.

Therefore, in order to move forward and suffice users requirements, we separated this into following:

Enhance profiles without introducing hierarchies: For which the proposal is mentioned here. This will support all those use cases which does not need settings hierarchy.
Support settings hierarchy outside Profiles: There is already a feature request for this - https://github.com/microsoft/vscode/issues/15909. We will do a brainstorming in this area to understand if a solution for this will cover this use case or if there are other options. We also believe that with proposed enhancements in profiles, it will give us a great chance to collect and understand the real time use cases related to settings and hierarchies in profiles from users. This will help us in coming up with a good solution.

Please note that supporting any new hierarchy in settings in not straight forward because this involves Model, UI and API changes. Hence separating them will unblock Profiles improvements and also focusing on most needed requirements.

sandy081 commented 1 year ago

You can now create a (partial) Profile, in which you can choose what configurations (Settings, Keyboard Shortcuts, Extensions, Tasks & Snippets) can be done in that profile and use the Default profile for some configurations. For eg:, you can have a Profile with all configurations except for Keyboard Shortcuts, and use Default Profile for it.

You can also share/apply a setting/extension to all profiles

These changes are available in insiders. Please try out them and provide us with the feedback.

mon-jai commented 1 year ago

@RoyalFoxy's method would be more intuitive for me.

In the current implementation, it is difficult to copy all settings from a base profile (I have to click "Apply Setting to all Profiles" for each settings, one by one). New settings also won't apply to other profiles too.

Instead of tracking setting keys that apply to all profile, maybe it would be better to also store the value?

// From
{
  "editor.fontFamily": "Fira Code, Consolas, 'Courier New', monospace",
  // 20+ more settings...

  "workbench.settings.applyToAllProfiles": [
    "editor.fontFamily"
    // Key of 20+ more settings...
    // Did I add all settings to the array? Is there something I missed?
  ]
}

// To
{
  "workbench.settings.applyToAllProfiles": {
    "editor.fontFamily": "Fira Code, Consolas, 'Courier New', monospace"
  },
  // Only settings defined outside `applyToAllProfiles` would not be inherited
  "some-local-settings": "value"
}

carlocardella commented 1 year ago

I used these settings with the first profile I created:

My intention was to create a test profile based on Default and I wanted to copy only extensions and User Tasks, but I got the opposite.

Definitely my fault, I didn't pay enough attention to the "Use Default Profile" label, I assumed I needed to check what I wanted to copy from the Default (because of the "Copy from: Default" dropdown I selected above).

I am not sure if/how this can be improved and made more clear: now that I know how the dialog works it seems straightforward and I think I like it, but I can imagine others making my same mistake the first (and maybe second) time.

tanishqmanuja commented 1 year ago

Totally agree, rephrasing the hints would be great. Something like: Settings - Use Default Profile => Using Settings from Default Profile Keyboard Shortcuts - Use Default Profile => Using Keyboard Shortcuts from Default Profile

sandy081 commented 1 year ago

@mon-jai

In the current implementation, it is difficult to copy all settings from a base profile

Copy from Default Profile option should be enough to do this.

sandy081 commented 1 year ago

Settings - Use Default Profile => Using Settings from Default Profile

Changed this to Settings - Use Default Profile => Using Default Profile. Having Settings multiple times might be redundant.

mon-jai commented 1 year ago

@sandy081 That was a typo. What I mean is,

In the current implementation, it is difficult to "synchronize" all settings from a base profile

If I understand it right, "Copy from Default Profile" is a one time operation. Subsequent changes to those copied settings won't be synchronized between profiles. Settings added after the copy operation won't apply to other profiles too.

I would like to have a "single source of truth" for all my global settings, instead of having to copy them over occasionally.

sandy081 commented 1 year ago

I would like to have a "single source of truth" for all my global settings, instead of having to copy them over occasionally.

You can unselect Settings option when you are creating the profile - This will use Settings from the Default Profile.

mon-jai commented 1 year ago

unselect Settings option when you are creating the profile

@sandy081 But then I won't be able to have "local settings" for the profile.

IMO, a common use case will be having a default profile with common settings for all languages, and a few language/framework specific profiles extended from default profile, with additional settings for the given language.

For example,

// Default profile
{
  // Common settings for all languages
  "editor.fontFamily": "Fira Code, Consolas, 'Courier New', monospace",
  "editor.lineHeight": 1.6,
  "editor.renderWhitespace": "trailing"
  // ...
}

// Python profile
{
  // Everything from default profile...

  // Python and Jupyter notebook specific settings
  "jupyter.askForKernelRestart": false,
  "notebook.output.textLineLimit": 100,
  "python.analysis.typeCheckingMode": "strict",
  "python.analysis.useLibraryCodeForTypes": true,
  "python.formatting.blackArgs": ["--skip-string-normalization"],
  "python.formatting.provider": "black",
  "python.linting.mypyEnabled": true,
  // ...
}

For now, it is impossible to inherit everything from the default profile automatically. We can either,

Click "Apply Setting to all Profiles" for each settings, one and one (new settings key won't be synchronized automatically, time consuming, error prone)
Unselect Settings option when creating the new profile (not able to define local settings)

It would be better if we could inherit settings from a given profile, with new changes synchronized automatically.

oldguan commented 1 year ago

i will create a new profile for python like above, but then the default profile is cleared. ahahah......

tanishqmanuja commented 1 year ago

@mon-jai, I am also having the same difficulty setting up my settings.json for individual language specific env (angular, python, golang etc etc). But i guess that has to do more with the settings.json and less with profiles in general. If extending is not possible to implement with multiple profiles (i.e. multiple settings.json), at least there should be a "fallback to default" approach instead of "follow default" approach.

// fallback would be something like this (we can discuss what merge strategy would be there)
effectiveProfileSettings = { ...defaultSettings, ...profileSettings }  // very useful IMO

// follow is simply this
effectiveProfileSettings = defaultSettings  // why would I even make a new profile to do this?

Like we have certain properties that can only be changed from settings.json (User), maybe some boolean property can be added to settings.json (Profile) to enable fallback to default.

sandy081 commented 1 year ago

@tanishqmanuja Please check my comment - https://github.com/microsoft/vscode/issues/156144#issuecomment-1616012963 . Can you please mention the real time use case for having default profile settings overridden in profiles?

@mon-jai It seems your use case does not seem like overriding setting. If you want some settings to be common for all profiles you can use the action to apply each setting or you can directly add the list of common settings to the following setting in settings.json of default profile.

"workbench.settings.applyToAllProfiles": [
    "editor.fontFamily",
    "editor.lineHeight",
    "editor.renderWhitespace"
  ]

In the background, settings common to all profiles are stored in this setting.

sandy081 commented 1 year ago

@oldguan

i will create a new profile for python like above, but then the default profile is cleared. ahahah......

Do you mean the settings in the default profile are replaced by the settings from the profile template? If so this is a bug and should be fixed. Thanks for letting us know about this.

Edit: Fix is on the way...

tanishqmanuja commented 1 year ago

@sandy081 My real-time use case is beyond the scope of this issue, but that said if overriding is added would make my IDE experience much better. Still here's a simplified version of the use case :)

Default

These settings define my basic vscode styling. Obviously if I like my vscode to look a certain way, i would keep that for all profiles.

// default user settings
{
  "editor.fontSize": 14,
  "editor.fontFamily": "MonoLisa",
  "editor.fontLigatures": true,
  "editor.minimap.enabled": false,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.tabSize": 2,
  "editor.codeLens": false,
  "editor.bracketPairColorization.enabled": true,
  "editor.overviewRulerBorder": false,
  "editor.hideCursorInOverviewRuler": true,

  "terminal.integrated.fontSize": 14,
  "terminal.integrated.fontFamily": "MonoLisa Nerd Font Mono",
  "terminal.integrated.gpuAcceleration": "on",

  "workbench.startupEditor": "none",
  "workbench.sideBar.location": "right",
  "workbench.colorTheme": "One Dark Pro Darker",
  "workbench.productIconTheme": "fluent-icons",
  "workbench.iconTheme": "symbols",
  "workbench.colorCustomizations": {
    "editor.lineHighlightBackground": "#00000000",
    "editor.lineHighlightBorder": "#00000000"
  },
}

JS

Here i have to copy my default stuff + add few JS additions Obviously I don't want these on default profile.

{
  //copy default settings here.
  "[html]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascript]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[json]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  // other js extensions specific settings
}

JS Presentation

This profile is exactly same as JS but with font size enlarged to 16 to make screen sharing easier.

{
  //copy default settings here (except fontsize). (overriding would help here)
  //copy JS settings here.
  "editor.fontSize": 16,
  "terminal.integrated.fontSize": 16,

 // also disabling stuff like codium, and copilot
}

mon-jai commented 1 year ago

@sandy081 But keeping applyToAllProfiles in sync with every defined setting keys is troublesome and error prone.

Currently I have something like this (yeah It is a long list):

{
  "workbench.settings.applyToAllProfiles": [
    "[css]",
    "[html]",
    "[ipynb]",
    "[javascript]",
    "[javascriptreact]",
    "[json]",
    "[jsonc]",
    "[markdown]",
    "[powershell]",
    "[python]",
    "[scss]",
    "[typescript]",
    "[typescriptreact]",
    "[vue]",
    "apc.font.family",
    "apc.iframe.style",
    "apc.imports",
    "cSpell.userWords",
    "editor.cursorBlinking",
    "editor.fontFamily",
    "editor.fontLigatures",
    "editor.formatOnPaste",
    "editor.formatOnType",
    "editor.guides.bracketPairs",
    "editor.largeFileOptimizations",
    "editor.lineHeight",
    "editor.maxTokenizationLineLength",
    "editor.renderWhitespace",
    "editor.rulers",
    "editor.stickyScroll.enabled",
    "editor.tabSize",
    "editor.unicodeHighlight.ambiguousCharacters",
    "editor.unusualLineTerminators",
    "editor.wordWrap",
    "emmet.includeLanguages",
    "explorer.confirmDelete",
    "explorer.confirmDragAndDrop",
    "files.associations",
    "git.autofetch",
    "git.enableSmartCommit",
    "git.openRepositoryInParentFolders",
    "gitlens.plusFeatures.enabled",
    "gitlens.statusBar.enabled",
    "gitlens.views.formats.commits.label",
    "javascript.updateImportsOnFileMove.enabled",
    "prettier.configPath",
    "security.workspace.trust.untrustedFiles",
    "terminal.integrated.automationProfile.windows",
    "terminal.integrated.copyOnSelection",
    "terminal.integrated.defaultProfile.windows",
    "terminal.integrated.enableMultiLinePasteWarning",
    "terminal.integrated.profiles.windows",
    "typescript.updateImportsOnFileMove.enabled",
    "window.commandCenter",
    "workbench.colorTheme",
    "workbench.editorAssociations",
    "workbench.settings.applyToAllProfiles",
    "workbench.startupEditor"
  ]
}

That's why I suggest having applyToAllProfiles as an object instead.

{
  "workbench.settings.applyToAllProfiles": {
    "editor.fontFamily": "Fira Code, Consolas, 'Courier New', monospace"
    // ...
  }
}

sandy081 commented 1 year ago

I am closing this feature request with the solution that is current implemented.

I have created following issue to discuss about the support for overriding default profile settings in a custom profile. Those who are interested in this feature, please provide your use case / scenario (NOT how you want to use) for this requirement.

microsoft / vscode

Profiles: Extend from Default Profile #156144

176813

Default

JS

JS Presentation