You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A profile could be a name (e.g. "Java", "Note taking", "Markdown") associated with a number of extensions to toggle on, a specific theme to use, and some setup of workbench and panels (e.g. this or that panel hiden, or maximized, etc).
To create a new profile, a user would click a "New Profile/+" button, give their new profile a name, and then select the extensions (from the list of all the installed extensions) they want to associate with the profile, and the theme they want to associate with the profile.
So, when doing Markdown writing, a user could switch to his "markdown" profile, which will then toggle markdown and writing related (spell check, preview as PDF etc) extensions enabled, and use a profile-appropriate font.
Similarly, when doing Python, various Python linting, static analyzing, type checking, formatting, etc extensions can be loaded, as associated with a "Python profile".
There will of course be the default theme and "all installed end enabled extensions loaded" profile as the default case.
It would especially useful if the user could have multiple windows open with different profile each (e.g. a coding profile and a note taking or Jypyter related profile).
Also if it was possible to configure a "default" profile, for when the VSCode launches.
What we get with profiles:
a visual (because of the color theme and worspace adaptation) optimization of the UI for a particular task
less bloat/speed, when using VSCode for a particular task (as we only load the extensions required for the task)
There is already talk about allowing Terminal profiles #119366 ) , and this feature request is basically the same concept, but for the whole workspace.
This is a similar suggestion, but about settings (could be combined with this as a superset): #116740
This one is probably the closest to my proposal: #95182 though mine is more narrow scoped, and perhaps easier to implement.
The text was updated successfully, but these errors were encountered:
VSCode could have an idea of "profiles".
A profile could be a name (e.g. "Java", "Note taking", "Markdown") associated with a number of extensions to toggle on, a specific theme to use, and some setup of workbench and panels (e.g. this or that panel hiden, or maximized, etc).
To create a new profile, a user would click a "New Profile/+" button, give their new profile a name, and then select the extensions (from the list of all the installed extensions) they want to associate with the profile, and the theme they want to associate with the profile.
So, when doing Markdown writing, a user could switch to his "markdown" profile, which will then toggle markdown and writing related (spell check, preview as PDF etc) extensions enabled, and use a profile-appropriate font.
Similarly, when doing Python, various Python linting, static analyzing, type checking, formatting, etc extensions can be loaded, as associated with a "Python profile".
There will of course be the default theme and "all installed end enabled extensions loaded" profile as the default case.
It would especially useful if the user could have multiple windows open with different profile each (e.g. a coding profile and a note taking or Jypyter related profile).
Also if it was possible to configure a "default" profile, for when the VSCode launches.
What we get with profiles:
a visual (because of the color theme and worspace adaptation) optimization of the UI for a particular task
less bloat/speed, when using VSCode for a particular task (as we only load the extensions required for the task)
There is already talk about allowing Terminal profiles #119366 ) , and this feature request is basically the same concept, but for the whole workspace.
This is a similar suggestion, but about settings (could be combined with this as a superset): #116740
This one is probably the closest to my proposal: #95182 though mine is more narrow scoped, and perhaps easier to implement.
The text was updated successfully, but these errors were encountered: