-
Notifications
You must be signed in to change notification settings - Fork 34.6k
Description
Goals
In some scenarios, it's possible for the debug adapters to provide a quality debugging experience without additional user configuration. For example, the new js-debug
can debug npm scripts, and languages where entrypoints are easily identifiable. Go, C#, Java... may offer to debug the program without extra configuration.
In a similar way to how build tasks are provided, we'd like the ability to provide default run tasks that show up under the Select and Start Debugging
quick-pick.
Proposal
Launch configurations already have an optional presentation
key, with the following properties (this interface is not exposed in vscode.d.ts):
export interface IConfigPresentation {
hidden?: boolean;
group?: string;
order?: number;
}
This proposes adding a new property:
export interface IConfigPresentation {
+ locations: ('debug.start' | 'debug.selectandstart' | 'debugView')[];
When set, this configures the locations in the UI where the returned configuration is displayed. If not provided, the locations returned from DebugConfigurationProvider.provideDebugConfigurations
default to ['debug.start']
. provideDebugConfigurations
would now be called when the select and start quick-pick is opened to retrieve configurations to display.
Questions
-
Why are we proposing this over the existing initial configuration/F5 experience?
- It's hard (impossible?) to discover if you have any configured launch configurations, you don't get the quick pick again;
- Start debugging is contextual to the active text editor file, where the these tasks are intended to be project-level.
-
Should we surface all existing provided configurations in select and start?
- + this would require no change to existing adapters
- - existing returned tasks are contextual to the active editor, while select and start currently only displays project-level configurations.
- - the names of most existing tasks are simply "Node.js" or "Go", which don't provide explaination and would confuse users in select and start.
-
Should there be a separate method to return the pick-able configurations?
- + in this proposal, we start calling
provideDebugConfigurations
more frequently, which may lead to side-effects or slowdowns; a separate method avoids that. - + this proposal is somewhat of an overload to the existing method to potentially return a new (non-contextual) type of task.
- - this proposal has a smaller API and the property fits in well with the presentation properties
- - the API here allows configurations to be surfaced in multiple locations easily, including "Run and Debug" if we want to allow that.
- + in this proposal, we start calling
-
Should we also be able to provide default configurations for the "Run and Debug" dropdown in the debug view?added- + this is most discoverable for users who don't enter through the command palette
- + allowing this as an option in
locations
would let consumers in launch.json take advantage of it, rather thanhidden: true/false
. - - in cases where there are many discovered tasks (e.g. lots of npm scripts) this could get noisy
- - would we need to call provideDefaultLaunchConfigurations every time the debug view is opened? If files change, would we call that again?