Allow debug extensions to show diagnostic information in the breakpoints view

[connor4312]

js-debug has a breakpoint helper to diagnose issues. It's there and there's some heuristics for when we show a notification, but notifications are disruptive, thus the heuristics are conservative, and thus not many people know about the tool. Something that could be helpful is a contribution point that would show markdown text below the breakpoints in the BREAKPOINTS view. js-debug could embed a command link there to open the diagnostic tool, and use a when clause to show it at appropriate times.

[rebornix]

👍

I was bugging @connor4312 for unbound breakpoints in a project which has a wrong webpack output config. Due to the misconfig, the source maps are wrong. It would be helpful the unbound breakpoint has some tooltip/hover as suggested above and send to me a diagnostic/troubleshooting view.

[roblourens]

I think a link in the breakpoint hover message would be more discoverable

[rebornix]

The hover message of breakpoint is markdown, we can double check if it's command enabled.

[roblourens]

Is it ok to just allow command links in the markdown hover @connor4312 ? I think that's discoverable, I hardly ever look at the breakpoints view in the debug pane.

[weinand]

The initial comment proposed to "show markdown text below the breakpoints in the BREAKPOINTS view" which seems to be discoverable.

Having the additional information in the breakpoint hover makes sense too, but that location is not very discoverable.
Are users really hovering over unbound (=grey) breakpoints to read the hover message?

If we go this route we should use a visual cue (e.g. a small 'i' badge in one corner of the grey breakpoint icon) to make users aware of the additional info. For this we might have to extend DAP so that a client can detect that there is "additional info".

[roblourens]

Are users really hovering over unbound (=grey) breakpoints to read the hover message?

To me this is a natural thing to do, like hovering squiggles in the editor. When something is confusing, I hover it to get more context. To me it's less natural to set a breakpoint, see that it didn't work, then go find a different view to get context on it.

[roblourens]

On the other hand, command links in breakpoint messages are a vscode-specific concept in DAP, we might not like that.

We can explore the breakpoints view text direction too. Are there any other uses for it except this kind of hint?

[weinand]

I'm not saying that we should show the additional information in the breakpoints view only. I'd like the additional info in the breakpoint hover.

My point was that most VS Code debugger users won't hover over grey breakpoints in the gutter because they already know that it means "unbound" and they do not expect to find more information there. This is different to problem icons where only the hover reveals the real info.

An 'i' badge on the breakpoint icon could help here.