Debug viewContainer menu contribution points

[thegecko]

Apologies if this is too similar to existing requests, but I'm keen to pull together a common request for adding debug contribution points.

Similar requests:

• Add context menu contribution point to Watch Variables Pane #150161
• Disassembly view: introduce context menu #129536
• Disassembly view: context menus #171548

And related:

• Investigate debug visualization extension points #197287

Rationale:

Debugging often needs deep integration between views (e.g. embedded debugging) where they are all driven from a common context and can interact with other. A common way to add these links/commands is through contribution points and some of the provided debug views lack these extension points. Can I suggest contribution points in context menus for the following:

• Watch view (e.g. to open the value in a memory viewer)
• Breakpoints view (e.g. to expose a 'run to breakpoint' command)
• Disassembly view (e.g. to show source, manage breakpoints, show memory)
• Debug viewlet bar (e.g. to add a command to launch a custom GUI to create a complex debug configuration)

I assume this is the debug viewlet:

Happy to work on a PR if this is of interest.

[roblourens]

I am open to these for areas where the data type in the list is represented in the extension API already (eg Breakpoints). For others, like variables, that would involve having to think about how that type should look presented to an extension, which would take more effort.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[roblourens]

I guess we actually have this for variables already

[thegecko]

I guess we actually have this for variables already

We do, the ask is to consider this for some of the other views

[vscodenpa]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[theIDinside]

I am open to these for areas where the data type in the list is represented in the extension API already (eg Breakpoints). For others, like variables, that would involve having to think about how that type should look presented to an extension, which would take more effort.

I definitely understand the difficulty or that this isn't a trivial feature. But at the same time, when it comes to the debug adapter interface, we have a clear spec to adhere to. That's the API - and in a sense, no more, no less (though I'm sure there's always a bunch of new cool magical stuff one can add).

I think it would be neat if VSCode therefore exposed this functionality in a "bi-directional" fashion (sort of) as it's already well defined in the DAP spec. The debug adapter knows what data it gives VSCode, the DAP spec is clear on life times and object references and therefore it should not be that troublesome to pass that data back and forth - even outside of a normal "debug adapter request chain"; since the spec is clear that, for instance, variablesReference: 1 is only valid until the next resume request.

I don't know if this rant made any sense, but it's an attempt to spark a discussion in hopes of possibly moving something forward.

[thegecko]

Proposed contribution points covering this request can now be found in these PRs:

• Add viewContainer contribution point #212499
• Add debug window context menu contribution points #212501

cc @roblourens @isidorn

[roblourens]

Sorry for taking so long to look at this. I'll try to make some progress on it this week and get a discussion going about best practices for context menus here. It's not straightforward when we want to expose context types that don't exist elsewhere in extension API

[thegecko]

Sorry for taking so long to look at this. I'll try to make some progress on it this week and get a discussion going about best practices for context menus here. It's not straightforward when we want to expose context types that don't exist elsewhere in extension API

Great! I put some thought into the context types being exposed, feedback welcome.

[vs-code-engineering]

		Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting `\closedWith someCommitSha`, or directly add the `insiders-released` label if you know this has already been releaased

[roblourens]

Verification steps: you can enable the contribViewContainerTitle proposal, contribute a command to the viewContainer/title menu, but it only works for the debug viewcontainer and you must set viewContainer == workbench.view.debug in the when clause.

[amunger]

from the sample here, I could get a contribution into the callstack context menu and the debug toolbar, but not in the watch viewlet.

also, this contrib didn't seem to change anything

"viewContainer/title": [
				{
					"command": "extension.helloWorld",
					"when": "viewContainer == workbench.view.debug"
				}
			]

[thegecko]

roblourens closed this as completed in https://github.com/microsoft/vscode/pull/212499[last month](#200880 (comment))

Please be aware this request is implemented through multiple PRs and isn't complete.
The addition for disassembly, watch and breakpoints is in #212501
@roblourens could you reopen please?

....I could get a contribution into the callstack context menu and the debug toolbar, but not in the watch viewlet.

Please be aware the example covers multiple PRs which aren't yet all merged:

• Add debug window context menu contribution points #212501
• Add viewContainer contribution point #212499

...also, this contrib didn't seem to change anything

The restriction for viewContainer == workbench.view.debug was added after I wrote the example.

[roblourens]

Opened #227169 to track the rest of it. This issue is just for the view container menu. @amunger if you're expecting to see the icon for your command, you can ad "group": "navigation", otherwise it's in the ... menu.