Small enhancements to temporary debugger console

[markm77]

I appreciate the temporary debugger console option (powershell.debugging.createTemporaryIntegratedConsole). But it suffers from some small usability issues.

(1.) It is configured in settings as a global option rather than per launch config when actually it configures launch config behaviour. This means if we need to turn it on and off (for example to avoid continual re-attach with C# debugger) it's not very convenient.

(2.) There is no ability to perform a second round of debugging in the temporary debugger console without re-creating the process which hampers further investigation of an issue.

I would like to suggest the temporary debugger console option become two launch config options: (a.) "console selection": allows launching debug session using separate debugger console rather than normal integrated console (and in such case doesn't re-create debugger console if already present) (b.) "force new console": re-creates console before starting debug session (could apply regardless of console selection)

These two options would allow much more flexibility with launch configs and allow having a stable process for C# debugger attachment when using the debugger console.

[TylerLeonhardt]

(1.) It is configured in settings as a global option rather than per launch config when actually it configures launch config behaviour. This means if we need to turn it on and off (for example to avoid continual re-attach with C# debugger) it's not very convenient.

There's already an option in the launch config:

        {
            "name": "PowerShell Launch Current File in New Terminal",
            "type": "PowerShell",
            "request": "launch",
            "script": "${file}",
            "cwd": "${file}",
            "createTemporaryIntegratedConsole": true
        },

[rkeithhill]

Beat me to that by like 5 secs! :-)

[markm77]

Okay, great sorry to miss this. But could we consider splitting into two options as mentioned?

This would allow e.g. all kinds of benefits when working with a C# debugger. A persistent debugger console would give a stable process to attach against. While also allowing to easily drop the debugger console for C# rebuild/republish. Debugging could then start immediately with a new debugger console auto-generated.....

[TylerLeonhardt]

@markm77

allows launching debug session using separate debugger console rather than normal integrated console (and in such case doesn't re-create debugger console if already present)

Why do you need this instead of just using the normal PowerShell Integrated Console?

[markm77]

Why do you need this instead of just using the normal PowerShell Integrated Console?

That is what I've been using. But (a) process re-starts of the main console are really slow - much slower than "trash-canning" the debug console (which is instant allowing immediate ability to type new commands into the main console), (b) I lose any other "static" context in the main console, (c) I now need the aforementioned slow re-starts for both C# rebuld and fresh-state debugging the combination of which occur quite often.

[markm77]

Basically I think giving a little more flexibility with the lifecycle of the debugger console would support both my scenario above and also the scenario of wanting to do further debugging within an already-created dubugger console.

Anyway appreciate you giving this your consideration. Have a nice day!