Interactions with other views

[jreineckearm]

Description

It would be useful to add more places to invoke the Memory Inspector for easier discoverability and increased productivity. This could include opening the Memory Inspector from

• Main/View menu (would be an empty window instance)
• Variable value, currently only from variable address
• Watch entry/expression
• Register value in variables window, for example to show top of stack stored in a stack pointer Not a must for this task collection. And could also become a more debug adapter specific solution. For example Arm Debugger and Arm Embedded Debugger extensions have a split out register window.

Additional information

[planger]

Related microsoft/vscode#200880

[tortmayr]

It would be useful to add more places to invoke the Memory Inspector for easier discoverability and increased productivity. >This could include opening the Memory Inspector from

Main/View menu (would be an empty window instance)

@jreineckearm Unfortunatley we are hitting the limits of the VS Code API here. Direct contributions to the main menu bar are not allowed. Contributions to the View menu are only possible for real Views, so this does also not work because the inspector is a custom editor.

However there are some other options we could explore for entry points to the memory inspector :

• Allow to open a inspector via command palette (Open new Memory Inspector)
• Add a icon menu item to the Debug view toolbar (debug/toolBar contribution point)
• Add a icon menu to the Tile menu (editor/title) of the memory inspector that allows opening a new additional instance
• Maybe add an icon to the the title menu c/c++ text editors (when a supported debugsession is running)

Wdyt?

Regarding:

• Watch entry/expression
  This is currently blocked by Debug viewContainer menu contribution points microsoft/vscode#200880 as we have no way to contribute context menus
  to the watch view.

[jreineckearm]

@tortmayr , my apologies I missed your last comment.

Allow to open a inspector via command palette (Open new Memory Inspector)

Yes, this would be a good approach to at least have one way to open a new view without the need to go through for example the variables view. May need to engage with the VS Code project itself to enable contributions to the main menus outside the scope of this issue here.
Don't we have commands already that just need to be added through the extension manifest?

Add a icon menu item to the Debug view toolbar (debug/toolBar contribution point)

You mean the run control toolbar, right. It may get crowded there if we add buttons for other views as well. Probably not now.

Add a icon menu to the Tile menu (editor/title) of the memory inspector that allows opening a new additional instance

This could work. But may need more opinions than just mine. :-)
Could possibly be a kind of "duplicate" button to transfer local settings from the existing one as a starting point.

Maybe add an icon to the the title menu c/c++ text editors (when a supported debugsession is running)

Interesting idea. But the editors may not be a good context for that functionality. May however be something for future embedded debug views. Maybe from the built-in disassembly view? But I think that one has at the moment only little contribution points...

[jreineckearm]

Maybe add an icon to the the title menu c/c++ text editors (when a supported debugsession is running)

@tortmayr , on second thought: would it be possible to add something to the editor context menu? Maybe even with extra info when right-clicking on a variable that is consumable by the view? Similar to the context menu entry that shows up on suitable variables in the variable window?

[tortmayr]

Don't we have commands already that just need to be added through the extension manifest?

Yes we do. It's currently only enabled when the "memory-inspector.canRead context key is true.
But we can simply remove this condition so that we can open a new view at any time.

Add a icon menu to the Tile menu (editor/title) of the memory inspector that allows opening a new additional instance

This could work. But may need more opinions than just mine. :-)
Could possibly be a kind of "duplicate" button to transfer local settings from the existing one as a starting point.

Sounds interesting. A "duplicate" option also synergises well with the "freeze" feature. (Duplicate view and freeze one to have both a snapshot and "live memory").

Maybe add an icon to the the title menu c/c++ text editors (when a supported debugsession is running)

Interesting idea. But the editors may not be a good context for that functionality. May however be something for future >embedded debug views. Maybe from the built-in disassembly view? But I think that one has at the moment only little >contribution points...

Contributing a button to the title menu of the Dissasembly view should be possible. So we could at least open a new (empty) memory inspector from the view.

@tortmayr , on second thought: would it be possible to add something to the editor context menu? Maybe even with extra info when right-clicking on a variable that is consumable by the view? Similar to the context menu entry that shows up on suitable variables in the variable window?

Adding to the editor context menu is possible. However scoping this to consumable variables might be tricky. I think the necessary information could only be provided by the underlying LSP.. @martin-fleck-at LSP & Text editor integration more your area of expertise. WDYT?

[martin-fleck-at]

Adding to the editor context menu is possible. However scoping this to consumable variables might be tricky. I think the necessary information could only be provided by the underlying LSP.. @martin-fleck-at LSP & Text editor integration more your area of expertise. WDYT?

Without actually testing it for now, I'd be surprised if you got any useful information out of the context of the text editor context that really helps you determine the variable name and context. It might be possible but definitely not straight-forward. @jreineckearm If you want I can look into this in more detail.

[jreineckearm]

But we can simply remove this condition so that we can open a new view at any time.

Oh, my bad. This is available now. It wasn't with earlier versions but only opening the "Memory Inspector" Output window. Ignore this part. I remember now that this was fixed now.

Contributing a button to the title menu of the Dissasembly view should be possible. So we could at least open a new (empty) memory inspector from the view.

I think that wasn't possible a while ago. But there was an open issue at VS Code. Maybe it is enabled now. If it is, then yes, that would be useful.

However scoping this to consumable variables might be tricky.

@tortmayr , @martin-fleck-at , no need to investigate this now. It would have been a nice to have on top. But can be addressed later if the expected effort is unknown and presumably high.