altimmons
commented
5 years ago And a proposed, unifying solution
Making a few- small, not breaking changes would solve most of my and most other peoples issues with configuration. Briefly, it involves unifying the settings files (Keybindings, Tasks, Launch, Snippets, Settings, and WS.code-workspace) and allowing referencing in a tree like fashion. This is much more clear, much more extensible, backwards compatible and much more capable.
Briefly I propose, everything remains as is. With one exception, in each of the parsers for User settings, Folder Settings and Workspace Settings an additional recursive subroutine \method\function is added. Making an option something like this:
//#myworkspace.code-workspace
{
"include": [
{
"profile.name": "markdown-light",
"path.to.file": "markdownsettings.code-settings"
},
{
"profile.name": "java-general",
"path.to.file": " javalanguageprofile.code-settings"
}
],
"settings": {
"debug.allowBreakpointsEverywhere": false,
"debug.enableAllHovers": true,
"debug.inlineValues": true,
"debug.openDebug": "openOnSessionStart"
//...
//<perhaps many more>
//...
},
"extensions": {
"recommendations": [
//[Editor Helpers]
"albert.TabOut",
"weakish.complete-statement",
"CoenraadS.bracket-pair-colorizer-2",
"aaron-bond.better-comments",
"oderwat.indent-rainbow",
"predrag-nikolic.php-class-helper",
"maptz.camelcasenavigation",
"kevinkyang.auto-comment-blocks",
//[Other]
"eriklynd.json-tools",
"Tyriar.shell-launcher",
"helixquar.asciidecorator",
"rexebin.classlens",
"marlon407.code-groovy",
"ArgyleWolfLabs.vscode-groovy",
//[git]
"ankalus.git-tools",
"codezombiech.gitignore",
"donjayamanne.git-extension-pack",
"donjayamanne.githistory",
//[Markdown]
"jebbs.markdown-extension-pack"
],
"unwantedRecommendations": [
//I used to carefully fill this out but I realized theres no point, it doesnt do anything.
]
}
}
An Included File
Then we include the included 'profile' file, which is code-worrkspace settings and all the other general settings types (or any of the settings types in one - tasks, launcher, snippets, keybindings, settings, color-customizations, extension specific settings.
//Markdown-light
//this is my snap in configuration for markdown editors when used within other projects - usually for documentation. etc.
{
"extensions": {
"enable": [
//<list of enabled exts>
"markdown.ext.vs.code"
],
"prohibit": [
"linter.markdown2"
],
//then presumably, because SOMEONE uses those recommendations, allow recommendations here-
"recommended": {
[]
},
"unwanted recommendations": {
[]
},
},
"settings": {Aside
Here are settings they are treated the same as if they were in the file which included them.
This way you can have a config for a single extension. Or a whole workflow.
It is suggested thus that the settings here be related to the task, for instance this calls in markdown settings into my java workspace, so it would have the markdown settings I use.- in addition to the settings for the above mentioned extensions. Big picture nothing changes, - everything is processed as before, just users are given much greater control over the config process.
And- Importantly if you're paying attention- this makes a recursive tree. Each of the @includes is a node with a name. We can snap-in or purge that tree, and if it has subtrees, they can be purged as well. So for instance we may have-
Global ---Java - a java Config which itself has 2 includes -EditorCustomizations -SpringBoot - settings for a spring boot build and the related extensions it depends on -- Project A settings -- Project B settings -RevA-Overwrites some of the earlier configuration with new settings \ \ \ \ \ \
Feature within a Feature Request
WHILE I AM AT IT. CAN WE PLEASE JUST GO AHEAD AND ENABLE THIS SYNTAX- It's like you went halfway there with the code-workspace configuration. But you didnt go all the way to the logical conclusion- which is why there are so many config related issues. Just make it so that the following members are all considered top level members-
. ...1-Settings ......Editor Config .........Landuage Specific Settomgs ...Workspace Config ......-(themes) .........-Workspace Configuration/ Overrides .........-TextMate, tokenization Configs/overides ... 2-Extensions ......- Include ......- Exclude ......-Recommend ......-Dont Recommend(?) ... 3-Keybindings ... 4-Snippets ... 5-Launch Config ...6- Tasks ... ?- Others I forgot, or future extensiability.
Then Includes __is like a meta top level- since its above all the prior, equivalent, and beneath- as shown in examples above or below. This is no different then what happens now, as settings can be defined at the Global, Workspace and Folder Level. Perhaps we restrict Paths / Launch/ and Tasks to at least 1 level deep- technically only Defaults exist at the highest level. Anything can be rewritten by the layer(s) below.
In addition to Settings, Extensions, and Paths, which may be defined where ever they fit in the users arrangement of setting configuration. Just parse the tree. If you hit a paths block, add the paths. Users can snap in and out paths with a command- since each @include is essentially a switch._
Continue the same doc as above
//continuing
},
"tasks": {
// <exactly the same as the current tasks file just nested- parse until you hit the closing bracket, and pass the entire chunk to existing parser. Its JSON so its fast and easy to do.>
},
"launch": {
"version": "0.2.0",
"configurations": [
{
"type": "java",
"name": "CodeLens (Launch) - App",
"request": "launch",
"mainClass": "main.App",
"projectName": "p3hencoding",
// "debugServer": 4711
},
],
},
"snippets": {
"ConvertLink": {
"scope": "markdown",
"prefix": ".linktitle",
"body": [
"[$1](${TM_SELECTED_TEXT})",
"",
"$0"
],
"description": "Take a site and make it into a link"
},
"SelectToLink": {
"scope": "markdown",
"prefix": ".selectedTextToHyperlink",
"body": [
"[${1:${TM_SELECTED_TEXT}}](${CLIPBOARD})",
"",
"$0"
],
"description": "Take a site and make it into a link"
},
{
//etc
}
},
"tasks": {
"version": "2.0.0",
"presentation": {
"echo": true,
"reveal": "always",
"clear": false
},
"type": "shell",
"echoCommand": true,
"tasks": [
{
"label": "initialize",
"dependsOrder": "sequence",
"group": "build",
"command": "mvn",
"args": [
"initialize"
],
},
{
"label": "VALIDATE",
"dependsOrder": "sequence",
"group": "build",
"command": "mvn",
"args": [
"validate"
],
},
]
},Say, I have lots of keybinding customizations. Maybe just to make the file prettier I want to break it out. Maybe I want to break it out bc its language specific and I call it in the language specific file Ive got here (Markdown)
"keybindings": {
{
"include": [
{
"profile.name": "markdown-keybindings",
"path.to.file": "mkdnkeys.code-settings"
},
],
},but I still define a few here anyway as well- for expediency. The two are equivalent.
{
"key": "ctrl+` ctrl+`",
"command": "shellLauncher.launch"
},
{
"key": "ctrl+k ctrl+k",
"command": "workbench.action.openDefaultKeybindingsFile"
},
}\Finally, perhaps we want this recursive- the "include" aspect- where include appears as a meta top level domain.
"include": {
[
{
"profile.name": "spring-boot",
"path.to.file": "spring-boot-settings.code-settings"
},
{
"profile.name": "maven",
"path.to.file": "maven-setup.code-settings"
},
]
},
"settings": {
"git.enabled": true,
"window.zoomLevel": -1,
"python.terminal.executeInFileDir": true,
"better-comments.highlightPlainText": true,
"editor.acceptSuggestionOnEnter": "smart",
"[markdown]": {
"editor.showFoldingControls": "always",
"editor.foldingStrategy": "auto",
"editor.fontLigatures": true,
"editor.accessibilitySupport": "off",
"editor.cursorBlinking": "expand",
"editor.cursorSmoothCaretAnimation": true,
"editor.copyWithSyntaxHighlighting": false,
"editor.defaultFormatter": "vscode.markdown-language-features",
// "editor.defaultFormatter": "jebbs.markdown-extended",
"editor.fastScrollSensitivity": 7,
"editor.formatOnPaste": true,
},
"markdown.preview.openMarkdownLinks": "inEditor",
"include": [
{
"profile.name": "workbench customlook2",
"path.to.file": "work"
},
{
"token.color.name": "mylintersettings.json",
"path.to.token.color.defs": "editor.tokenColorCustomizations",
"other.settings" {
"workbench.iconTheme": "material-icon-theme",
"markdown-preview-enhanced.codeBlockTheme": "atom-dark.css",
"markdown-preview-enhanced.mermaidTheme": "dark",
"markdown-preview-enhanced.previewTheme": "atom-material.css",it can appear as a field within any of the other levels (just like key bindings). Since I have a name, I can turn it on and off. Turning off a parent - in this case the parent we just filled out above Markdown-Light would turn this off too, as its a child node.
We can also declare a few settings within the include block for expediency.
"markdown-preview-enhanced.revealjsTheme": "night.css",
"materialTheme.accent": "Blue",
"workbench.colorTheme": "Hopscotch (TextMate Theme)",
"editor.fontFamily": "Fira-Code, 'Fira Code Retina', monospace",
}
]
]
}
}I hope this all makes sense. I think it will drammatically improve the capabilities of VS Code with minimum effort. I am open to other thoughts, and would love to see this get the attention of some of the Dev team.
RMacfarlane
sandy081
vscodebot[bot]
Issue Type: Bug
Multiple Extension and Workspace related Implementation inconsistencies/bugs
workbench.extensions.action.enableAll, not workspace specific extensions.*.code-workspace: `"extensions": { "recommended" : [ ] } does not reliably execute. Reliably Enable, Or even reliably suggest. I'd say it suggests half about a quarter of the time. 3- "Unwanted Recommendations" has no discernible effects. It does not disable extensions upon loading a code-workspace. There is a CLI command to enable an extension but not disable making scripting harder. 4-Having a *.code-workspace as a child of the root it describes - e.g. "path" : ".." causes unpredictable behavior, which keeps it from staying in the .vscode folder with its friends.I use several languages. I have elaborate configs for each of them, that are constantly changing- as I am sure many of us do. I have a Java config, a python config, a PlatformIO config, a markdown config, and then a slew of others I dabble in.
I don’t want all the extensions running all at once. As I have discovered more and more useful extensions, my vs code would slow to a crawl and become unreliable.
So now I make heavy use of workspaces. I change the settings for each by dropping a file in each directory as needed. A new java project gets my java config dropped in the root, that has several hundred lines for customization and settings.
I use the *.code-workspace file to set my configuration. I have fewer and fewer global configs as I find exceptions to where I'd want each thing.
Ideally though, I would have some way of replicating a workspace that I have gotten just perfect - after hours of neurotic tweaking- in a new workspace. Managing which extensions stay enabled and which are to be disabled is still very poor at this late stage of dev.
You can't enable extensions from the command line you can only disable. So we can’t manage extensions our self in any fashion. We can’t do it in the work-space settings. And cant do it via a script. I have to manually SEARCH and FIND each extension and enable it and disable others each time I switch tasks.
I have trouble managing the extensions which are enabled for each given task/workspace. When I work on a python file/ws I want all my python settings/extensions. Likewise Java. These settings may (obviously ) conflict and extensions interfere and react strangely.
So- the obvious solution is *.code-workspace- you’d think right. Except it doesn’t work like its supposed to.
I carefully set up the recommendations section in that file. But VS Code could care less. It only sometimes listens to my suggestions (if I put it in the file, its more like an "!important" or required than a suggestion... It might enable half. And leave extensions enabled from the last file I worked on. Even if I set up unwanted extensions. That does essentially nothing. I have Suggestions enabled in settings. I WANT them to take effect, and install. And if I list unwanted extensions, they shouldn’t just not recommend, they should NOT RUN.
HERE is the actual bug / implementation issue
So them I try from the Command Processor
>Disable all extensions(workbench.action.reloadWindowWithExtensionsDisabled)Then, execute Reload Workspace Extensions (
.extensions.action.enableAllWorkspace)Expectation
All the extensions listed in
ws.code-workspacewould be enabled. So I have started with a clean slate, then enabled the Workspace ones. I should have ONLY the workspace extensions running now.Actuality
However, this enables ALL extensions. Not the ones given in the workspace config.
I expect that to occur with the command (
.extensions.action.enableALL), not…enableWorkspaceI expect that command to execute what is in
*.code-workspace. while I might expect the commandworkbench.extensions.action.enableAllto enable everything.SO there are two things here in error.
Here is a third bug/ implementation issue. Having a *.code-workspace as a child of the root it describes causes odd – non-specific behaviors. It is convenient to put all my settings in root/.vscode (with tasks, launch, snippets) and set the path to parent – e.g.
”path” : “..”Or”path” : “.\..” or”path” : “../.” or whatever else you want to do to represent the relative parent (even./.././.././rootname/Discussion
You guys seem undecided about implementing workspaces in general. Its not very easy. Its actually quite complicated. Its why I have read the documentation all the way through on the VSCode website all the way through several times.
BY Default Code installs all extensions in the (what I will call) Global User Directory
%user%/.vscodeon Windows,~\.vscodeon Linux, and we all know there aren’t any real programmers on Mac (too busy editing videos and photos all day – or pretending too, while mailing Tim Cook their retirement assets) noticed today just a minute ago, there’s a little publicized command on the CLI code command for Extensions Management--extensions-dir <dir>(fromcode -h) that I think is new (?). maybe not.But I messed everything up swapping around my user dir on my Linux laptop (running code as root triggers a new user profile)- opening back as a regular user again not everything works like it should.
I suppose perhaps a possible intent is to make a local extensions directory for each project or class of project. I have an idea for a work around, I guess I will have separate user dirs. and extension dirs. for each language. – this could be why there is a
.vscodesettings dir in the local project, and a .vscode config dir on the Home dir of Win and Linux. But this isn't very clear. I have read all the documentation (ALL of it,, several times) and there’s nary a mention. So, is the intent that we run code like an IDE, with plugins, or are we running it like a NPM / maven project, where we have local extension sources for each project. Its a pain to go and redownload them all again. Further- unwanted suggestions is worthless as implemented. Taking the name literally, it does what it says it does maybe- I never checked- to suppress suggestions. But it does not disable an enabled extension shifting between projects. These should be regarded as contraindicated extensions- incompatible with the workspace. It shouldn’t just suppress a recommendation- I ignore that toast box most the time anyway. Its only useful if it does some action. I don’t know – maybe you guys are passing around multi root of Node/NPM/Electron/.js/.css builds VS Code (Insiders) all day, and this setting made sense.Finally, I like everyone else, my global user config eventually becomes littered with the detritus of the settings from scores of extensions that I installed but didn't live up to their authors promise.
Things like this become rather common:
There must be a better way to manage these extensions. Its critical I believe-- VS Code is so popular because of its extensibility. But it becomes unmanageable as more and more good extensions come out, and VS Code continues its move towards a one IDE for all solution.
We need portable profiles that we can engage and disengage and most importantly encapsulate.