Change:
Reminded of this by We currently have a context key (when clause) for the run menu (in the main menu). This means we don't know if the menu should be displayed on startup because it depends on extensions. The Terminal menu also has a context key but resolves very quickly so there is no delay. Should we remove both of these when clauses in favor of keeping them around with possibly disabled menu items. E.g. The "Install additional debuggers" entry should still be shown in the run menu if no current contexts are available.
Assigning to who now owns the Debug UI. Rob let me know if I can help here.
Which menu are you talking about? How is the context menu involved?
Context Menu should have been Context Key. Sorry about that, I'll edit the original post.
Looks like has decided to go this route with the Terminal menu, so I think we should align here too.
So the terminal menu will be shown all the time in web? That's what will happen with Run. I guess it will show "Install additional debuggers" And should other items be disabled or missing? They currently use so are missing. It would look like this <img width="245" alt="image" src="https://user-"I'm fine with that if it's consistent. Sort of gives false hope about what you're going to find, though
Actually, if the Run menu doesn't have a when clause, but all the subitems do and it is false, then the Run menu still doesn't show up. Would that be ok or is that still slow?
Won't install additional debuggers always be visible?
It currently has a when clause to only show up when other debuggers are present, it would only show up if I remove that. And I think "install additional debuggers" usually won't give the user what they want.
I see that entry as a way for users to discover how to get our web-based code execution extensions like Python. Maybe the text is not right? We could even have a web specific entry that filters the extension list to web-supported debuggers instead of all?
Yeah, I think that when those exist we should think about what the onramp looks like. For now I'll remove the when clause on the Run menu if you think that's the right thing to do.
sounds good, thank you
Ok, this actually isn't working the way I thought it did, and the result is that the Run menu never shows, at all. I must have tested it wrong, maybe you have to restart vscode for native menu changes to take full effect? The current state is that the Run menu has no when clause, and every command inside the menu does have a when clause. But the result seems to be: If the menu doesn't have a when clause, but initially doesn't have any enabled commands inside it, then it doesn't appear and will never appear, even if the commands inside it later get their when clauses flipped to true. The only way to get it to conditionally appear is to add a when clause to the menu itself. Does that sound like a menu bug But also I can just go back to having "Install additional debuggers" enabled all the time, I think that's fine.
that very well could be a menu bug. but thinking about it, I think having the one item always in the menu is necessary because otherwise we still result in the behavior where we don't know for some time on startup whether to show the menu or not which causes flickering.
is it expected that all of these items in the run menu are active in web? <img width="163" alt="image" src="https://user-"
You probably have some extension enabled for web which claims it can debug
Mock Debug and Python, thanks

Discussion:
original: 'Run', mnemonicTitle: nls.localize({ key: 'mRun', comment: ['&& denotes a mnemonic'] }, "&&Run") }, <del> when: ContextKeyExpr.or(CONTEXT_DEBUGGERS_AVAILABLE), </del> order: 6 });