Editing model for the memory viewer, feedback needed

[haneefdm]

This is a tricky one for me as we are not talking about editing files here. I only envision limited editing -- a byte here, a byte there, kind of thing. I am not expecting major bulky edits. Regardless, here are a couple of models

First of all, edits will only be allowed when the debugger is in paused state. Keep in mind that we are not part of the debugger or VSCode debug infrastructure. We are observers. We only find out the current state after a transition has already occurred. For instance, when a continue occurs, it takes us a while for us to find out.

Saving model (this must be decided first)

1. Instant: Save as you go. As you modify each byte, it will be saved instantly if possible. If the write fails, the user is notified and we revert the byte(s) back to its original state. Writes can fail because perhaps the debugger already continued or perhaps we are looking at a non-writable section. Even though the debugger supports write requests, you could still be looking at areas that are not writable. You will have a visual indication as to which bytes have been modified.
2. Batch: all the edits until you hit the Save button (explicit save command). This is what normal editors do. The danger here is that the user may have continued while some edits are unsaved. We will lose those edits.

Would be good to find out what other IDEs do. Eclipse uses the instant saving mode. This is what I am inclined to doing as well.

Undo/Redo

1. All undo/redo stacks are on a per stopped-session basis. ie, when the program continues, the undo stack will be cleared. Will be enabled on the next stop.
2. Undo/Redo will follow whatever saving model we use above

Cut/Copy/Paste

1. Cut: not allowed. Will be the same as Copy. This means, that we will not shift all the memory left when a byte is cut. Remember we are kind of an infinite scroll....so.
2. Copy: We put the selected cell(s) into the clipboard. But, what to put in the clipboard.. Surely not the hex bytes? Or the hex-bites as one format (text) and binary data as well. There may be some work to be done for how to select multiple disjoint cells, but lower priority.
3. Paste: Not sure how the clipboard works. It can contain multiple random things. Sure we can accept anything because it is random binary data. But doesn't seem right. It won't even work

It has been a long time since I worked with Clipboards so, I have to take inspiration from others. HexEdit is only place to look and maybe even make the formats compatible.

[haneefdm]

Comment by @benmcmorran. I had to manually move this comment from haneefdm/memview repo

One thought that comes to mind is that other extensions will likely already know which memory sections are writable (e.g. from an SVD). I haven't thought through the details too much yet, but it could make sense to provide an extension API so that the memory viewer knows which sections are safe to write to (or even read from). We end up doing something like this in our peripheral view, where we attempt to read memory in large chunks but break up the reads as needed when there are unreadable sections specified in the SVD.

EDIT: After some more discussion, it's clear that this wouldn't work for the bulk memory that users would probably be using a memory viewer for. It makes sense for looking at peripheral registers, but that use case is better served by a dedicated peripheral view.

[hongshui3000]

1.Instant: Save as you go. As you modify each byte, it will be saved instantly if possible. If the write fails, the user is notified and we revert the byte(s) back to its original state. Writes can fail because perhaps the debugger already continued or perhaps we are looking at a non-writable section. Even though the debugger supports write requests, you could still be looking at areas that are not writable. You will have a visual indication as to which bytes have been modified.

At least that's how it works in the debuggers I've used. As long as I write a certain byte or half word or word, it will save it at any time.In addition, the mem display can generally be configured as 8bit, 16bit or 32bit display

[hongshui3000]

Similar extensions seem to already support write mem https://github.com/eclipse-cdt-cloud/vscode-memory-inspector

[haneefdm]

I do know how to write memory and do it in other extensions! It is all the other stuff I have to do. I am leaning towards the Instant method as well. Except, this is not a high priority for me. I will get to it eventually

Similar extensions seem to already support write mem https://github.com/eclipse-cdt-cloud/vscode-memory-inspector

Btw, did you actually try this extension?

[hongshui3000]

I tried to try it, but he didn't seem to be compatible with cortex-debug, and then I gave up. I might try again later

[haneefdm]

I tried to try it, but he didn't seem to be compatible with cortex-debug, and then I gave up. I might try again later

I doubt it. We both follow the same debug protocol and I would have heard about it if there was a compatibility issue. I don't think they released it yet. Did you find it on the marketplace?

You may like that extension better anyways since editing is super high on your list. I don't know when I will get around to it.

[hongshui3000]

They did not publish it, I just compiled it myself, but I found that it seems impossible to write, although it seems to be implemented in the code. I didn't try too much later, I thought there was some incompatibility in the protocol, maybe my guess was wrong

[haneefdm]

Nope, I did not see the write implemented in the code yet. That is why it is not published yet, more than likely. How can there be incompatibility? I know who these people are. They had been using the same protocol with the SVD-viewer and we use it with the rtos and memory views. You should ready their code carefully. I did not see any write implementation and it is not a big deal. It just a few lines of code. I am done explaining this to you. Writing is easy. All the other stuff around it like undo stack, user interface, etc.