Continue improving "Run and Debug" experience

[roblourens]

The "Run and Debug" experience with no launch.json and no open editor could be improved further. See notes from #146338 (comment). Also,

• The last selected dynamic debug config should not be remembered - this can be fixed
• Maybe, always show welcome view when not debugging?
• Look at how to avoid activating some extensions when pressing Run and Debug
• Can the package.json contrib point for initial configurations be deprecated in favor of dynamic configurations?

[elahehrashedi]

This issue might be related to this thread:
"Add Configuration" is not working when triggerKind is vscode.DebugConfigurationProviderTriggerKind.Dynamic.

[roblourens]

Works fine for me, can you explain some more what happens? Didn't check but I think this would be "initial" triggerKind

[elahehrashedi]

@roblourens Add Configuration only works when we register the debug provider with initial triggerKind. The C/C++ extension is using Dynamic triggerKind now, to avoid creating a launch.json. However, that causes Add Configuration to not function anymore.

[roblourens]

I think "Add Configuration" will always create a launch.json, that is the idea of that command as far as I'm aware. So you want to run "Add configuration" to start debugging without a launch.json?

[DanTup]

So you want to run "Add configuration" to start debugging without a launch.json?

Is that the same as what the Debug: Select and Start Debugging command does? If so, maybe there should be an additional entry here - one for creating the config, and one for running an automatic one without creating a launch.json?

[elahehrashedi]

I think "Add Configuration" will always create a launch.json, that is the idea of that command as far as I'm aware. So you want to run "Add configuration" to start debugging without a launch.json?

We want to start debugging without creating the launch.json, which using the Dynamic provider is doing that for us.
However, with Dynamic triggerKind, the Add Configuration is not working.

maybe there should be an additional entry here - one for creating the config, and one for running an automatic one without creating a launch.json?

I think that is right. An additional entry for creating the configs would be useful.

[roblourens]

Add Configuration will create a launch config, that is the point of that command. But you will have to register for Initial to use it. I think that it's a little confusing that Initial configs will just run in some scenarios and go towards a launch.json in others. It makes the distinction between Initial and Dynamic a little confusing and we should think about that some more.

[elahehrashedi]

But you will have to register for Initial to use it.

@roblourens we have registered for Dynamic, but we would like to have this feature to still work. Right now we have added a separate "Add Configuration" button for our extension to add configurations to a launch.json. But it would be helpful if this feature works.

[roblourens]

I think I'm not clear on which scenario you're trying to avoid by not registering for Initial?

[vadimcn]

I believe the scenario @elahehrashedi is referring to is this:

1. I create launch.json (manually or otherwise) and save it.
2. I want to add another configuration, so I either choose "Run/Add Configuration..." from the menu, or open launch.json and click the [Add Configuration...] button on the bottom-right.
3. VSCode shows a list of all "configurationSnippets" compiled from all extensions that provide these in their package.json.

I would have expected that if my extension registers a debug configuration provider with DebugConfigurationProviderTriggerKind.Dynamic, its provideDebugConfigurations method would be invoked to contribute to this list. But this isn't happening.

Between "initialConfigurations", "configurationSnippets", "DebugConfigurationProviderTriggerKind" (btw, is it an enum or bit flags?) and the fact that when starting debugging without launch.json, the first method invoked on the debug config provider is resolveDebugConfiguration, and only if that one returns a null, will provideDebugConfigurations be invoked, makes the story around debug configurations very confusing. I don't know if this feature be rationalized at this point while keeping the API backward-compatible, but please at least document it!

[JustinGrote]

@roblourens I ran into this problem revamping the debug configurations for the Microsoft PowerShell extension.

This button:

only pulls from the hardcoded JSON in configurationSnippets rather than what I provide in provideDebugConfigurations. I tried running a debug with breakpoints and it never even hits the code path.

This however works just fine and how I expect:

Is there a good reason why these two appear to use different code paths? They seem to be accomplishing the same goal.

A major advantage of having dynamic launch configs is that I would be able to discover an initial entrypoint, but still allow them to change it, rather than relying on ${file} or some other special variable.

I am registering for both Initial and Dynamic

        [
            DebugConfigurationProviderTriggerKind.Initial,
            DebugConfigurationProviderTriggerKind.Dynamic
        ].forEach(triggerKind => {
            context.subscriptions.push(debug.registerDebugConfigurationProvider("PowerShell", this, triggerKind));
        });