Provide a bit more accurate "reason" for debug stop.

[rkeithhill]

It turns out that when the debugger stops at a function breakpoint, it isn't necessarily obvious why the debugger stopped. There is no breakpoint glyph for a function breakpoint. So if we return "function breakpoint", then VSCode will display "PAUSED ON FUNCTION BREAKPOINT" in the call stack viewlet. Hopefully that will help the user know why the debugger stopped.

See related VSCode issue - microsoft/vscode#3648

[daviwil]

I like this style for ternary operators, cleaner than the one I normally use.

[daviwil]

Awesome! Looks great.

[KirkMunro]

Could you please call them command breakpoints? They aren't function breakpoints, they are command breakpoints. They work for aliases, functions, cmdlets, and even executable applications.

[daviwil]

At the protocol layer we're speaking in VS Code's terms so that we're consistent with their experience. In the core library layer we'll definitely want to call them command breakpoints for sure. We'll get all of our terminology straight as we start cleaning up the APIs for 1.0 later this year.

[rkeithhill]

Yeah, we are trying to match the VSCode UI experience:

This is one of those compromises you make when you're plugging into a multi-language editor like VSCode. BTW this is where the reason is used:

When plugging in these services into ISE, ISE would use more PowerShell specific terms.

Hmm, looking at this again I see a type in the service that I do need to rename FunctionBreakpointDetails to CommandBreakpointDetails. I'll do that later tonight.

[KirkMunro]

Since VSCode is a multi-language editor, and since some of these languages may either (a) not have functions/have functions called something else (subroutine, procedure, etc), or (b) not have function breakpoints/have function breakpoints that are called something else, maybe a suggestion should be logged against VSCode that the terminology should change to command breakpoint in order to serve all languages better.

[rkeithhill]

Or perhaps VSCode could allow the extension to define a preferred alias for function breakpoints which it would honor in the UI (primarily the tooltip you get when you hover over the Breakpoints "+" button)? That could get tricky because VSCode is pushing for localization and I don't think the PowerShell extension is "there" yet.

[daviwil]

Localization is something I'm not looking forward to...