Breakpoint classes have no property for triggered breakpoints

[pmoura]

When creating a new triggered breakpoint and handling debug.onDidChangeBreakpoints events, there's no breakpoint property that allows distinguishing between a unconditional breakpoint and a triggered breakpoint so that a language extension can perform any required actions. This could be solved by adding a waitFor ~string~ location property, similar to the existing properties for the other types of breakpoints.

[roblourens]

Can you explain the problem some more? What does a language extension need to distinguish them for?

[pmoura]

How else can a language debugger know that it should only break at the triggered breakpoint if the specified breakpoint was hit first?

In the particular case of the language extension that I'm developing, the debugger tool is able to handle all types of breakpoints except triggered breakpoints as VSCode BreakpointsChangeEvent argument doesn't provide the necessary information.

[pmoura]

Also, the Breakpoint classes provide condition (for conditional breakpoints), hitCondition (for hit count breakpoints), and logMessage (for log points) properties. What makes triggered breakpoints an exception here? Why not keep the breakpoints API consistent?

[pmoura]

If you're curious about the actual language extension code, its repo is at:

https://github.com/LogtalkDotOrg/logtalk-for-vscode

The function that handles the breakpoints is defined at:

https://github.com/LogtalkDotOrg/logtalk-for-vscode/blob/79a140fa0bfaf8e459cf505f9923362843c4f9af/src/features/logtalkTerminal.ts#L828

The Logtalk debugger tool runs in the integrated terminal with the communication of the breakpoint changes using a proxy vscode object.

[roblourens]

I see, it looks like you're basically using extension API to implement something like a debugger, rather than a debug adapter using DAP: https://code.visualstudio.com/api/extension-guides/debugger-extension

But yeah, I guess triggered breakpoints haven't made it to the extension API yet. They are fairly new.

[pmoura]

I'm looking into a partial, inline implementation of a debugger adapter. But it's not yet clear if it will work due to mismatches between VSCode and the language debugger and their features and limitations. In the particular case of triggered breakpoints, these are already supported by the language debugger and only the missing waitFor (or similarly named property) in VSCode *Breakpoint classes prevent the integration here.

Thanks for adding this feature request to the backlog. Looking forward to its implementation, which I hope will be fairly simple.

[connor4312]

You may also want to check out the DebugAdapterTracker which lets you inspect communication to a DA