Vscode: Sub menus for Editor Context Menu

[DonJayamanne]

Can we have the ability to define sub menus for editor context menus (possibly to the editor/title men too).
For instance when adding menu items for refactoring there could be plenty of refactoring items:

• Extract variable
• Extract method
• Extract constant
• Rename
• Move class
• Change signature... etc

I believe adding all of them to the context menu without adding them as sub menus could result in a cluttered UX.

[ungod]

+1

[TheMegaMatt]

+1

[mike-lischke]

May I asked about the current status of this FR? Given that we have this patch since more than a year, I wonder when we can actually use submenus in our extensions?

[DanTup]

As well as being able to add items to a sub-menu, we should be able to do this dynamically (eg. with a request to a provider, not just declarative) so that we can disable/hide refactors that are not applicable to the current position/selection.

[jrieken]

@DanTup Regarding all those linked issues pointing towards more refactoring, please sync with @mjbvz and me about our new code action types. Idea is that you predefine certain code action types, e.g. this is about extracting and we then populate the light bulb and a (new) refactorings menu for you. See https://code.visualstudio.com/updates/v1_20#_codeactionprovider-improvements

[DanTup]

@jrieken Yeah, I've somewhat changed my mind a little since the last comment. I thought we had a lot of refactors that are available "for the whole file" and would result in lightbulbs no matter where the cursor is; however there actually seem to be very few.

So for now, this isn't a big deal to me - however the idea of adding things like refactors/light bulbs to context menu has come up several times in discussions about visibility. I have noticed that the lightbulb sometimes doesn't seem very noticeable hovering over code (did it used to be in the gutter?).

[mike-lischke]

Hmm, is this FR about a different way to add refactoring support or a general FR for submenus? I had the impression, it's the latter. I need a sub menu for various actions my extension can do for a (grammar) file, like showing some graphs, profiling details etc. This is not related to refactoring and hence cannot (and should not) be covered by the light bulb menu.

[DanTup]

I think it was a general request for context menus; which I requested can be contributed dynamically (eg. not declarative, so we can handle a request for a context menu and choose what to put in there asynchronously), but possibly I also derailed a little about having lightbulbs shown in there too.

[jrieken]

Yeah, this issue is about adding sub-menus but it seems that @DanTup implements various refactoring commands and those we wouldn't like to see as separate commands but to integrate into the platform - it's similar to us not liking separate format or rename commands. However, for code actions (refactorings & quick fixes) it's more fuzzy and that's why we have the new API in place

[3dots]

Hello. Has this FR petered out somewhat? Or does this have a chance of being put in?

I just checked out a highlighting/marker extension, and figured: can't be that hard to make a context sub-menu which lets you toggle a highlight based on a list of colors already used in the file... Turns out it's not that simple after all.

So, umm, does this mean you need to pipeline all that through the Lightbulb instead?

[caadam]

+1 for this request. I'm implementing an extension that has a Visual Studio like treeview and require a context menu that has multiple levels to keep the UI manageable.

[phiter]

updates on this? I wish I could create an extension to create new file from a template like they do in PHPStorm

[rockxsj]

+1

[swjain23]

Any update on this? We want to group commands to support adding new files from template, like in Visual Studio:

[ghost]

Do we have this already? Because I'm seeing this:

V1.41.1

[gjsjohnmurray]

AFAIK it's not yet possible for extensions to contribute submenus. See https://github.com/microsoft/vscode/issues/85218#issuecomment-556081709 for my hope that it'll come soon.

[damgot]

I'm also interested on it.
I've so many command in my extension's editor context menu... I really need to be able to arrange them in sub-menus

[viceice]

We love to see that too. Want to use it in the standalone monaco editor.

[sentry07]

Another +1 from me. Grouping editor/context commands into sub menus would be amazing to have.

[gjsjohnmurray]

@jrieken until now you have (understandably) resisted requests for extensions to be able to contribute menu items that get computed dynamically (i.e. at the point where the context menu is about to be displayed).

Would you consider permitting this for submenus, when (as many of us hope) it becomes possible for an extension to contribute submenus?

For instance, my extension might add an "Extra Stuff" submenu entry to the editor/context menu in such a way that when the context menu appears it shows Extra Stuff > and invokes an async function in my extension to return the computed contents of my submenu. A cancellation token would allow the menu handler to cancel my compute if the user dismissed the first-level menu before I had supplied the submenu contents. And if the user's interaction with the context menu requests display of the submenu before the async function has completed, maybe show a spinner in place of the > on the menu entry.

[Blaiski]

Another +1 from me too. It's been four years since this feature has been requested. Is there any hope we might be getting it soon, please? Anyone who can see that it's just impractical to expect extensions to keep adding their menu items all at the top level? @gjsjohnmurray I also add my voice here. I need to compute and generate my submenus dynamically so I'd expect to be able to do them using async functions just like the case with showQuickPick

Thank you

[zesluo]

just wondering, is it available now for adding submenu to context menu? Thanks

[gjsjohnmurray]

just wondering, is it available now for adding submenu to context menu? Thanks

Now available in Insiders as a proposed API, slated for finalization in in the next-but-one release.

[zesluo]

Thanks for your reply! @gjsjohnmurray , May I know when it will be public?

[gjsjohnmurray]

Thanks for your reply! @gjsjohnmurray , May I know when it will be public?

The related issue (#100172) Is currently showing as on the September 2020 milestone, meaning it's slated to ship in Stable in early October.

[joaomoreno]

Closing this, since it's done in master.