Implemented Indexable ByteValue Indications

[stricklandrbls]

• Added indexable indication array for ByteValues within the viewport displays.
• Created categorical byte indiciations values & CSS selectors.

Screenshot: ByteValue Search Result Indication

Screenshot: ByteValue Replace Result Indication

Replacing 0x 00 00 00 -> 0x FF 01 FF

Closes #784

[stricklandrbls]

Issue Resolved

There seems to be some unintended merge changes between this branch and main that I did not change myself. These following items are marked as being removed:

• src/language/dfdl.ts
• src/providers/attributeHover.ts
• src/providers/attributeHoverItems.ts

I'm currently working on resolving this.

[NolanMatt]

Looks good

[stricklandrbls]

I've come across a bug in the on:click event propogation while re-basing another ticket to include this PR's changes.

I'm currently working on a fix for this.

[scholarsmate]

I hope to get to this review tomorrow.

[stricklandrbls]

The issue I ran into was due to the fact that I moved the listener events for the highlight selection. Previously, there were listeners for each ByteValue but it was less load on the extension to have a single listener at the ByteValue container level, then parse which element fired the event.

There are two separate on:mousedown and on:mouseup events that are distinct but the child components during a single byte selection only have on:click events. This meant that the parent container was still registering the mousedown and preventing a full click/release cycle needed for a click.

[scholarsmate]

This is a nice new feature. We can see replaced sequences.

We can select a range of bytes to edit.

We can select a single byte to edit in-line.

One minor inconsistency is that we we can close the multi-byte selection using the X in the 3rd column, but we lack that for the single byte selection. To "escape out of" single byte mode edit, ESC works, but doesn't "escape out of" multi-byte edit mode. It would be good to have ESC and the X work for both selection modes.

Things get more complicated when changes are made, then undone. The highlights are now incorrect when changes have been undone. It would be good to have the highlights work with undo/redo.

[stricklandrbls]

Things get more complicated when changes are made, then undone. The highlights are now incorrect when changes have been undone. It would be good to have the highlights work with undo/redo.

The issue with the undo / redo seems to be within the fact that there's no longer a history of changes being kept with messages between the extension, server, and UI. I believe this was changed with the search & replace got restructured to be incremental search & replace. Those messages being sent don't contain any data.

I think ideally, when redo/undo changes are made, there should be some data in the server-extension-UI pipeline to have the UI accurately display the viewport. Similar to how the scrollViewport, viewportRefresh, and requestEditedData are done.

That being said, something should be done to rectify this highlighting issue but will have to be in sync with what changes are going to be made to search / replace in the future.

[scholarsmate]

@stricklandrbls, that's right. If a 1M file of 'a's gets changed to 'xX' that's a lot to keep track of and will not scale well. I'd recommend doing the same here. Just highlight the last replacement and the current search. There will be no highlighting for replace all or replace rest since that's all done on the server side and is opaque on the client side.

If I insert or delete bytes the highlights float on top and do not float with the content. If I delete or insert bytes in the middle of a selection, it doesn't shrink or grow. If I revert all changes, the highlights remain.

Maybe the "fix" is to clear the selections when any edit is made or any change is undone/redone. I think it's still possible to show the last replacement and the current search, but any other change to the content clears the selections.

[stricklandrbls]

... If I delete or insert bytes in the middle of a selection, it doesn't shrink or grow. If I revert all changes, the highlights remain.

Can you elaborate on this one? I was able to make a selection and have the highlights grow & shrink according to the length of the edited segment.

[scholarsmate]

@stricklandrbls, I was deleting and inserting into the highlights from a search and replace. The selection you're showing is concerning unless "overwrite only" is the selected editing mode. It just grows the length of the replacement string. If I'm not in "overwrite only" mode and I select 3 bytes and I replace that with 10 bytes, I need those 3 bytes replaced with the new bytes (growing the file by 7 bytes), not just overwrite 10 bytes with 10 new bytes.

[stricklandrbls]

I need those 3 bytes replaced with the new bytes (growing the file by 7 bytes), not just overwrite 10 bytes with 10 new bytes.

Is that not fundamentally how the applyChanges event works? Even on the extension side the message data members are:

• originalDataSegment - The selected data from the unedited viewport perspective.
• editedSegment - The segment of data to replace the original.
• offset - Where in the viewport to apply the overwrite.

The highlights are based off the byte length of the selectionDataStore

Here I append abc to PDF and the replacement results is PDFabc-1... growing the file by 3 bytes.

It might help if I have different indications for the raw, user-selected, selection and what is being appended / removed from that selection. Like something in the below gif:

[scholarsmate]

@stricklandrbls, these selections should not grow unless we're doing overwrite only. If we are doing overwrite only, I like the second GIF that shows what additional bytes will be overwritten if the changes are applied.

applyChanges by default effectively deletes the original segment, and inserts the new one. If overwrite only is used, it effectively overwrites the bytes starting at the given offset for the length of the edited segment. I say effectively because Ωedit™ has an algorithm to change one segment into another using the smallest change possible.

You could use Ωedit™ viewports to power the selections and keep them updated when changes are made. They are designed to track changes in data segments from a content perspective (use isFloating = true) or from a position perspective (use isFloating = false). In this case, we want the the viewport to move with changes in the content, so use isFloating = true. Ωedit™ can efficiently handle many of these for you and is one of the reasons for having floating viewports.

Here is an example in a TypeScript test of using a viewport to track some content in a session. It doesn't include what happens to the 'LABEL' if the label itself gets changed, but we can make it behave any way we want by subscribing to its viewport events.

[stricklandrbls]

The different highlighting for extending / shortening the byte selection via the editor panel, has been removed. Now, once a multiple byte selection has been made, only those bytes will be highlighted in the viewports. This is regardless of the size of the edited data segment.

[scholarsmate]

Rebased on the most recent main.

[scholarsmate]

The Search function isn't working properly:

As we navigate using the "seek to next match", we start seeing incorrect matches being highlighted.

It gets worse as we get to the last match.

The warning text is jumbled up.

This is neat though that it can handle overlapping highlghts.

To reproduce, just open package.json and search for Apache. You can see that no changes were made yet.

[scholarsmate]

+1

[arosien]

Question: I don't quite know enough to understand these additions, and to a newbie it seems like one is clearing changes right after the changes are sent, which is slightly confusing. Can you tell me more?

[stricklandrbls]

I'm on github mobile and have to poke around to see what this is referencing. I'll get back to you soon.

This is because the clear changes command will clear the changes that were made in the data editor and in turn clear the data stores that the byte highlighting is derived from.

The naming convention does seem a bit confusing but the this.sendChangesInfo() is sending "changes" in regards to the difference in changes made from Data Editor viewport edits and the associated file on this. Whereas, the webview message clearChanges clears uncommitted changes / edit from a user's selection from within the data editor.

I think they could both use a bit more expressive names: sendUpdatedFileInfo and clearUnsavedActivity perhaps.

[arosien]

👍

although i have a quick question posted