vscode.debug.startDebugging should support named automatic (dynamic) and global (user settings) debug configurations

[bersbersbers]

I'd like to use vscode.debug.startDebugging to switch between debuggers (compare #97921, where the proposed solution is to write an extension - I'd like to try this).

Unfortunately, vscode.debug.startDebugging is restricted to named configurations from launch.json files: that means, global (a.k.a. user settings) launch configurations are not supported, and neither are automatic (a.k.a. dynamic) debug configurations. This is according to the documentation here:
https://code.visualstudio.com/api/references/vscode-api#debug

A similar request has been made in #77782, but that was hidden in an issue about very specific compound configurations. The core issue is much broader.

Alternatively, there should be a way to query all debug configurations available to the user in the Run dropdown, without having to parse all possible json files.

[weinand]

@isidorn is there any reason why dynamic and user launch configs are not supported?

[isidorn]

They are not supported because we did not implement it. I do not think there are any real blockers. However there are open questions:

So the idea would be that calling
startDebugging(undefined, NAME) would search for User launch configurations with the NAME (since undefined was passed as a folder)?

Dynamic launch configurations: how would we know which debug extension you are reffering to? If you just pass the NAME we would have to ask for dynamic configurations from each adapter and see if any of the returned configurations match the NAME?

[weinand]

@isidorn both suggestions make sense.
And for dynamic launch configs we could rely on the newly introduced persisted "proxies".

[bersbersbers]

So the idea would be that calling
startDebugging(undefined, NAME) would search for User launch configurations with the NAME (since undefined was passed as a folder)?

That sounds reasonable to me, yes.

Dynamic launch configurations: how would we know which debug extension you are reffering to? If you just pass the NAME we would have to ask for dynamic configurations from each adapter and see if any of the returned configurations match the NAME?

One might turn the folder parameter into something like a parent parameter, which can represent either a folder or a debug adapter.

By the way, I noticed now that launch configurations can also be added from .code-workspace files, and maybe even from folder .vscode/settings.json file (although the latter does not seem to work right now). These should also be considered.

So maybe my alternative approach is the better suited one:

a way to query all debug configurations available to the user in the Run dropdown

With this, the developer would pull all (including dynamic, if optionally requested) debug configurations, pick the one they want, and pass that to startDebugging. In this case, name resolution of configurations would not even be an issue any more.

I don't care to much about the exact solution, but I would like to be able to programmatically start all debug configurations that the user can start, and that does not seem possible currently.

[weinand]

Please note that there is no deterministic way to enumerate "all dynamic launch configs" because they depend on the context.

[bersbersbers]

Please note that there is no deterministic way to enumerate "all dynamic launch configs" because they depend on the context.

Good point. I am thinking about a user command that would enumerate these configs, so maybe there is a way to pass on that command's context to the enumeration; or maybe enumeration simply uses the current GUI context.

[weinand]

the "context" for a dynamic launch config is "everything that is available to an extension". So it is unbounded and not known in advance.

[bersbersbers]

the "context" for a dynamic launch config is "everything that is available to an extension".

I understand this as "there is no one context object", so I guess my first proposal is impossible. But this should work, right:

maybe enumeration simply uses the current [GUI] context

When an extension's command is called, it can enumerate (in each call) all possible debug configurations at this point in time. (It does not need to be "deterministic" in the sense that I would enumerate them only once and cache them.) This should mirror pretty much what the user would see it the used the "Run" dropdown at that same point in time, shouldn't it?

[weinand]

If an extension tries to enumerate "all possible debug configurations at this point in time" it has to activate all extensions that provide dynamic launch configs. This is costly because many extensions download big amounts of additional code and data on activation. Doing all of this only to get a list of "all possible launch configs" is a waste of time and effort.

VS Code's UI (= "Debug: Select and Start debugging") in this area is different: only statically available launch configs are listed. For dynamic launch configs we only list the extensions that provides them. Only if a user explicitly selects an extension, VS Code activates and asks the extension to provide the dynamic launch configs. So instead of activating all extensions, typically none or only one is activated.

[bersbersbers]

If an extension tries to enumerate "all possible debug configurations at this point in time" it has to activate all extensions that provide dynamic launch configs. This is costly because many extensions download big amounts of additional code and data on activation. Doing all of this only to get a list of "all possible launch configs" is a waste of time and effort.

Thanks, I understand that. Still:

1. Currently, when working with a script file in programming language A (R) while having a debugger for language B (Python) selected, I need to manually open the side panel, go to "Debug", select a matching Debugger (dynamic or not), and then close the side panel again. Honestly, if I had the choice of having my (still imaginary) extension pull up a list of dynamic launch configurations (only if the selected debugger language does not match the current language), I would gladly wait a second or two.

2. Also, enumerating dynamic debug configurations might of course focus on a single extension: I imagine that installed extensions can be queried and filtered by language (in my example, R), so that I would query only those extensions which offer dynamic debugging for R.

[weinand]

@bersbersbers please consider a quicker way to select a launch config:

When working with a script file in programming language A (R), just press F1, then type "Select..." and pick the "Select and Start debugging" action.

In the QuickPick either

• pick a launch config for "R" from the recent "R" configs from the top of the list,
• pick a launch config for "R" from all items from the current launch.json,
• select the "R" debug type (folder icon at the end of the list) and then pick a dynamic generated launch config.

When doing this another time, the last selected launch config will show up at the top of the list without having to go through the two step process again.

[bersbersbers]

@bersbersbers please consider a quicker way to select a launch config:

When working with a script file in programming language A (R), just press F1, then type "Select..." and pick the "Select and Start debugging" action.

In the QuickPick either

• pick a launch config for "R" from the recent "R" configs from the top of the list,
• pick a launch config for "R" from all items from the current launch.json,
• select the "R" debug type (folder icon at the end of the list) and then pick a dynamic generated launch config.

When doing this another time, the last selected launch config will show up at the top of the list without having to go through the two step process again.

Thank you for this suggestion. Unfortunately, in terms of usability, this (F1, "sel", Enter, searching for the right entry and using arrow keys [note that omnibox filtering does not apply to names of extensions with dynamic debug configurations], Enter) is lightyears away from simply pressing F5.

[weinand]

Sure, my suggestion was not meant to be a quicker replacement for "F5".
My suggestion was a quicker alternative for your

"Currently, when working with a script file in programming language A (R) while having a debugger for language B (Python) selected, I need to manually open the side panel, go to "Debug", select a matching Debugger (dynamic or not), and then close the side panel again. "

And after having done this once, both dynamic launch configs (for R and for Python) will appear as "recent" entries in the "Select and Start debugging" quickpick, and can be found with name filtering. I don't see how your imaginary extension can be "lightyears ahead" of this...

But anyway. We do not have any plans do provide API for enumerating dynamic launch configs.

[bersbersbers]

Sure, my suggestion was not meant to be a quicker replacement for "F5".
My suggestion was a quicker alternative for your

"Currently, when working with a script file in programming language A (R) while having a debugger for language B (Python) selected, I need to manually open the side panel, go to "Debug", select a matching Debugger (dynamic or not), and then close the side panel again. "

I see. Well, I find both too elaborate for repeated daily use. Sure, I see why it's acceptable out of the box, and why you don't want to spend resources on exposing such (GUI) functionality. But the fact that I cannot even write my own extension for a shortcut is somewhat disappointing.

And after having done this once,

1. both dynamic launch configs (for R and for Python) will appear as "recent" entries in the "Select and Start debugging" quickpick, and
2. can be found with name filtering.

This is not the case for me, neither 1 nor 2:

(This is on 1.50.1 as well as on today's insider, fcac248)

But even if it were ...

I don't see how your imaginary extension can be "lightyears ahead" of this...

... an extension could provide a command that picks the best-matching (by whatever criteria, configurable or not) out of the available debug configurations and runs that. Always assuming that all debug configurations accessible by the user through the GUI can also be accessed programmatically...

But anyway. We do not have any plans do provide API for enumerating dynamic launch configs.

... and since that is not (planned to be) the case, of course an extension cannot do this (completely).

It would be great to at least have support for global and workspace launch configurations, though.

[weinand]

@bersbersbers

This is not the case for me, neither 1 nor 2:

This is a bug (or an incomplete implementation). I have create issue #110009 for this.

It would be great to at least have support for global and workspace launch configurations, though.

yes, that's the reason why we will leave this issue open.

[bersbersbers]

It seems to me that the new "serverReadyAction" action "startDebugging" supports something close to what I want - starting a debug configuration by name, regardless of the json file where it's coming from:

"serverReadyAction": {
  "action": "startDebugging",
  "pattern": "listening on port ([0-9]+)",
  "name": "Launch Browser"
}

https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_52.md#serverreadyaction-launch-other-debug-config-by-name

I do wonder: the release notes for 1.15 said

Since named configurations or variables are only defined in the scope of a folder, we had to add a folder argument.

Is this statement still true?

• If so, is the "serverReadyAction" action "startDebugging" restricted to starting debug configurations from the same file where it is defined? Is this documented somewhere? I could not find it.
• If not, I imagine the folder argument could be dropped from vscode.debug.startDebugging

[weinand]

@bersbersbers yes, the new "startDebugging" verb of the "serverReadyAction" is restricted.

@connor4312 we need to document this.