Support an extension point for customizing gutter interaction.

[changsi-an]

• VSCode Version: 1.18.0
• OS Version: 16.04.1-Ubuntu

Feature request

It will be useful to be able to control the pop-up menu when user right-clicks the gutter of a document:

• The feature should support adding to / replacing the existing menu items "Add Breakpoint" and "Add Conditional Breakpoint...", potentially based on the current document URI.

• Then it should be able to control the gutter glyph that would be added after the associated command is executed. It should give the command handler control over what the glyph will look like.

• After the glyph is added, the context menu will change. There should be a way to control what menu items should display in that menu after the glyph is added.

User Case

This feature is needed, so we can add another type of "breakpoint-like" object to the application's business model. And also disable setting breakpoints when setting a breakpoint scenario does not apply to certain documents.

[weinand]

@changsi-an what "breakpoint-like" object do you have in mind?
If we would support to introduce "custom breakpoints" in an extension (with their own icons, state, and custom interaction with the DA), would that help?

[changsi-an]

Hi @kenneth Auchenberg<mailto:Kenneth.Auchenberg@microsoft.com>, Can you help explain the LogPoints scenario to Andre? Thanks, -Chance

[weinand]

@changsi-an I think I understand the LogPoints scenario. From your initial description it wasn't clear to me whether you had more advanced "breakpoint-like" things in mind.

[changsi-an]

@weinand Yeah, we don't have a more advanced thing in mind other than LogPoints for now. Potentially more concepts very similar to LogPoints which we have not flatten out yet.

In regard to

we would support to introduce "custom breakpoints" in an extension (with their own icons, state, and custom interaction with the DA), would that help?"

custom interaction with the DA is not quite a concern. I believe we can already do that as long as we grab a DebugSession object. We should then be able to interact with it.

Without actually seeing a draft API, it is hard for me to speculate what you mean by with their own icons, state. I guess your "state"-based approach is a good one. Presumably, we are going to see a "breakpoint-like" object explicitly modeled as a type/Class. Then it has multiple states, with each state associated with a gutter glyph(icon) and a set of menu items, which will be shown when the breakpoint is right-clicked on the gutter. Among them, one state is a "off" state, with no icon and no menu interaction.

[weinand]

Since LogPoints are supported now, no further work planned here.