Repository navigation
Allow other extensions to query properties of the current configuration #1524
Description
I'm writing an extension that plugs in our companies build processes on top of vscode-cpptools. Stuff like generating c_cpp_properties.json, launch.json, etc...
Ideally, the user would have their workspace set up so that they've selected a configuration for intellisense, and when they hit F5, the appropriate launch.json configuration is selected for their selected c_cpp_properties.json configuration.
The easiest way I can think of would be to allow other extensions to query vscode-cpptools for the current configuration, and then clients can use that to get the name or any other property.
I'm still getting my hands dirty with extensions, so let me know if this already exists, or there's a better way to accomplish this.
Thanks!
Activity
sean-mcmanus commentedon Feb 6, 2018
VS code allows extensions to export functions that other extensions can call. So we could export some GetCurrentConfiguration method. Another potential option would be to store the current configuration name in a setting, and then the setting could be referenced using ${config.} in launch.json. We currently just save the current configuration as a number/index, which we send to the processes when the number changes. You should be able to implement this yourself with our open source typescript and we could accept a pull request.
thejcannon commentedon Feb 7, 2018
I think exposing the current configuration (as the full JSON) would probably be more beneficial to clients.
As far as exposing a function goes, I found a way of executing another extension's commands, is that what you're referring to? If so I think it would be easy to add a new command (that isn't attached to anything in the UI) that returns the current configuration.
sean-mcmanus commentedon Feb 7, 2018
I don't know what you mean by "exposing the current configuration (as the full JSON)". We currently use a c_cpp_properties.json that other extensions can read/write (the same way our extension does using JSON apis), but the currently selected configuration is not available anywhere. We plan to migrate away from that json file and just use the normal settings.json later though, although c_cpp_properties.json might still be supported for backwards compatibility unless do a conversion, in which case the currently selected configuration might just be a setting as well.
I don't think we want to add a "command", which are listed in the command palette for users to execute. I'm referring to returning a public API from our activate method: https://code.visualstudio.com/docs/extensionAPI/vscode-api#_extensions:
`Extension writers can provide APIs to other extensions by returning their API public surface from the activate-call.
export function activate(context: vscode.ExtensionContext) {
let api = {
sum(a, b) {
return a + b;
},
mul(a, b) {
return a * b;
}
};
// 'export' public api-surface
return api;
}
When depending on the API of another extension add an extensionDependency-entry to package.json, and use the getExtension-function and the exports-property, like below:
let mathExt = extensions.getExtension('genius.math');
let importedApi = mathExt.exports;
console.log(importedApi.mul(42, 1));`
thejcannon commentedon Feb 7, 2018
What I was hoping to expose was the contents of the configuration in c_cpp_properties.json for the selected configuration. (I.e. if I've selected configuration "A", and I ask vscode-cpptools for the current configuration, I get back the JSON object that contains
"name": "A").That sounds pretty promising, and would be pretty useful. Depending on the timeline, I could live without the feature I'm requesting if the feature you describe was implemented. Any idea on when that change might take place?
thejcannon commentedon Feb 8, 2018
Actually. If we just exposed the current configuration's name through settings.json, it would solve our problems (as far as needing the configuration exposed) and be a stepping stone to having vscode-cpptools exclusively use settings.json.
Would you be opposed to that solution?
sean-mcmanus commentedon Feb 8, 2018
Yeah, that sounds good to me. I can't think of any blocking problems that would cause (or a need to modify the language server process). Bob Brown (@bobbrow) Griffin Downs (@grdowns) Rong Lu (@ronglums) Do you guys see any issues? If the setting name doesn't match any names in the c_cpp_properties.json it should switch to the default and update the workspace setting to be valid. Did you want to add this yourself? I'm not sure when we'd be able to add it.
thejcannon commentedon Feb 8, 2018
I'd be happy to try 😄
sean-mcmanus commentedon Feb 8, 2018
Sure, let us know if you have any questions or want help with something.
bobbrow commentedon Feb 9, 2018
I think it would be better to export an API (it's something I eventually want to do for CMake integration anyway) than add a new setting for this. A setting opens up some weird cases since it can be set in any of three scopes (global, workspace, folder) and this really only ever applies to a folder.
Another potential option would be to write the active configuration index into the c_cpp_properties.json file (it sounds like you're reading the configs from there already?). I think I considered doing this at one point, but ended up using the persistent storage stuff instead to avoid incrementing the version number of c_cpp_properties.json.
We still haven't sat down and thought through the migration of c_cpp_properties.json to settings.json so I have concerns about adding a setting that has the potential to be obsoleted in a month or two. Exporting an API that can provide this information sidesteps any potential issues here and is the safest option, IMO.
sean-mcmanus commentedon Feb 9, 2018
The global/workspace scopes are still valid as defaults if the folder setting isn't set yet. The problem with the export API is that I don't think you can add that to a task/launch.json, which I assumed was a goal -- see #1444 for another recent user request.
Way back in December 2016, I was thinking about something like...
C_Cpp.includePaths: { “Linux: <> “Win32”: <> }Whatever the exact setting layout is, I don't think having the configuration name in a setting would become obsolete. Putting the configuration in the c_cpp_properties.json seems more likely to become obsolete.
bobbrow commentedon Feb 9, 2018
Fair point. I forgot about tasks.
thejcannon commentedon Feb 12, 2018
From a client's perspective,
settings.jsonis much easier to consume (since you can use${config:C_Cpp.foo}intasks.jsonorlaunch.json.From the perspective of an extension writer, it's easier as well since there's
vscode.workspace.getConfiguration()[C_Cpp].Which means there's no API to maintain for you guys.
8 remaining items
sean-mcmanus commentedon Feb 15, 2018
Another previous request was #742 .
thejcannon commentedon Feb 15, 2018
I can prototype a read-only setting and see how it turns out. Might feel clunky to the user, depending on some of the design decisions.
What I'm imagining is that if the user changes it to be invalid, it "snaps" back to the valid value. Similarly if the user re-configures the c_cpp_properties, it "snaps" to a valid value.
It's too bad I can't dynamically set enum values. That would be pretty useful 😃
sean-mcmanus commentedon Feb 15, 2018
What do you mean by "re-configures the c_cpp_properties"? What is being snapped to a valid value?
The package.json can be dynamically modified with different enum values, but the problem is that the change won't be picked up until the extension reloads.
thejcannon commentedon Feb 15, 2018
"re-configures the c_cpp_properties" means if the user removes some configurations (maybe the current one?)
"snapped to a valid value" means if they try to go from
"C_Cpp.configName": "Foo"to"C_Cpp.configName": "Food"(where "Food" isn't a valid name). The extension would (somehow) listen to the change, and change it back to"C_Cpp.configName": "Foo".Although I'll admit, I haven't thought about this in the context of the hierarchy of settings (global, workspace, folder).
I didn't know that was a feature, mind pointing me to the documentation?
sean-mcmanus commentedon Feb 15, 2018
Ah, the "it" you're referring to is the setting snapping to valid value and not the c_cpp_properties.json changing.
I don't think I've seen documentation on the package.json re-writing behavior. We do it in main.ts in the rewriteManifest() method and we also potentially do it in processCpptoolsJson() in abTesting.ts, but that code isn't currently hittable. We used to do more package.json re-writing for the debugger, but we got rid of that because users found the extra reload requirement annoying.
I think only the workspace setting (or folder setting for multi-root) would need to be snapped to a valid value because it takes precedence over the higher settings, e.g. a user may have an default config set that is only valid for 50% of the folders they open, so we wouldn't want to change the user setting.
bobbrow commentedon Feb 26, 2018
FYI, I've been discussing this with the VSCode team and asking them for a way to do this that doesn't require us to expose a setting or an API.
microsoft/vscode#43782
thejcannon commentedon Feb 26, 2018
I like the sound of that. It definitely allows for more interesting things, while keeping the active config private in the cpptools extension.
Enable ${command:cpptools.activeConfig} in tasks #1524
Enable ${command:cpptools.activeConfigName} in tasks #1524 (#3219)
sean-mcmanus commentedon Mar 2, 2019
We've added
${command:cpptools.activeConfigName}in our 0.22.0-insiders2 build: https://github.com/Microsoft/vscode-cpptools/releases . Let us know if you experience any issues with that.