Transform the editor in an actual view

[AdrianOltean]

Description
In the Eclipse-based implementation, we had the Memory and the Memory Browser views. These were really useful in an embedded development flow and it made it easy to inspect/visualize memory.

Current implementation of the Memory Inspector for VS Code creates editors for each attempt to inspect a memory area. In contrast, in Eclipse we had the Memory view with the possibility to add "monitors" and navigate between them in the same view. Mixing Memory Inspector editors with source code editors makes it difficult to use it.

Moreover, the feature is not easily accessible and doesn't offer intuitive ways of accessing it through the standard debug views, other than from Variables view or from Command Palette (that always starts reading at 0x0 - debatable for an embedded system).

Request is to transform the "inspector" into a view that can be positioned in one of the panels (e.g. alongside Problems, Terminal, etc.) in VS Code.

[planger]

@AdrianOltean Thank you for your feedback!

I think this is an interesting point, which also has been discussed a bit in the past. It revolves around the requirement to have multiple Memory Inspector instances open at the same time (each tracking a specific debug context), limited by the fact that VS Code views can only be opened once, while custom editors can be opened multiple times, but then custom editors cannot be put into the right panel of VS Code -- a limitation of VS Code.

So the current implementation -- being based on custom editors -- is a compromise prioritizing to show multiple instances, but accepting that you cannot put them into the right panel.

In the Theia Memory Inspector, we don't have this limitation as Theia is more flexible in this regard.

There might be certain workarounds and strategies in VS Code too, to improve the situation. For instance, we may register the Memory Inspector as both, a view and a custom editor, and always start out in a view, but let users break out into separate editors, etc. Also more context awareness in specific Memory Inspector views would be helpful, to allow showing and switching debug context in the view would be needed. But those strategies and their impact would have to be investigated more deeply.

If you are interested in contributing in this area, I'm sure you'll find several interested parties. So please feel free to discuss and propose this topic in the next CDT Cloud meeting, mailing list, or here on Github.

[AdrianOltean]

@planger Thanks for whole context. Most of our MCUXpresso for VS Code users have an Eclipse (MCUXpresso IDE) background. And the Memory / Memory Browser views from Eclipse are/were really used in an embedded development environment., so getting used to the new "editor" approach it's not a seamless transition.