Repository navigation
Give the MAT-file editor the dictionary editors' Properties refresh, safe save and backup ids, and share the table editors' message dispatch - #111
Merged
Conversation
…e, not only a reload The MAT-file editor told the inspector only when its tree was replaced from disk, so an edit, its undo or redo, a paste or a move out of the file left the panel showing the value from before until another row was clicked. Its document now says so after every repaint (onChanged), as the binary dictionary editor's does since #108, and extension.ts answers both with the inspector's one re-resolve; onReplaced, which this subsumes, is gone.
…rite both byte-backed editors share The MAT-file editor wrote the user's file through its own copy of what diskFollow.writeUserFile does for the binary dictionary editor: the replace, then the stamp the write left, read back by a stat where the write could not say (a folder deleted under the view, written again). It now calls writeUserFile, so the two editors save by one rule; the behaviour is the same, and a test holds the MAT-file's deleted-folder save to it, as one already holds the binary editor's.
…editor gives its own The MAT-file editor kept a private copy of backupId/backupSource, the format src/host/backupId.ts now owns for both byte-backed editors. It uses the shared module and its copy is gone. The format is the one it already wrote, so a backup it made before still restores; a test now also restores a MAT-file from a bare-uri id, the binary editor's older shape.
…ed from, by one rule The binary dictionary and MAT-file editors each spelled out the read that opens, reverts and reloads a document: the stat before the read (so a write between the two costs a needless prompt, never a silent overwrite), and, for a hot-exit restore, the backup's bytes under the stamp its id recorded. diskFollow.readStamped and readForOpen now say it once, and both editors call them. The save's own bookkeeping (saving, the conflict ended by a write) and the revert's stay in each provider: each is two lines around format-specific rollback, and the binary revert ends the conflict inside applyDisk, so a shared helper would be neither simpler nor exactly the same.
…the MAT-file and both binary editors ready, select, navigate, requestMatrix, requestChildren, undo and redo were spelled out in each provider's own if/else chain, with the same checks on what arrived (a selection that is no array, a link target that is no string) written again in each. tableDispatch.dispatchCommon now answers them from a table of handlers keyed by message type, which the MAT-file, binary dictionary and read-only editors pass; the JSON view follows later. The type makes the four every view owes required, and messageDispatch.test.ts reads each provider's table keys beside its branches, so it still holds every editor to its tier, and to answering no message twice.
# Conflicts: # src/host/inspectorSelection.ts
…table too The JSON view was the last table provider spelling ready, select, navigate, requestMatrix, requestChildren, undo and redo out in its own chain. It now hands them to tableDispatch.dispatchCommon from its CommonHandlers table, each doing what its branch did (the ready handshake marks the webview ready before it paints; the fetch fills the Usage column with its own annotator); locateInText and the editing messages stay its own. messageDispatch.test.ts now requires the table of all four providers.
…om the code The read-only viewer's "register listeners BEFORE assigning webview.html" note had ended up over the CommonHandlers table instead of the subscription it is about; it sits over onDidReceiveMessage again. The MAT-file document's onChanged doc named two call sites while there are three: a gesture that threw says the tree changed too, before its view paints every row again itself. An overlong comment line in binarySlddInspectorRefresh.test.ts is wrapped. No shared factory for the handlers the four providers' tables have in common: each is a one-liner over that provider's own callbacks, and messageDispatch.test.ts and matrixRequest.test.ts read each table's keys off the provider's source, which a factory would hide from them. Comments only; no behaviour change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes the MAT-file editor work like the dictionary editors where they still differed, and shares the message dispatch every table editor repeated.
onChangedhook as the dictionary editors, fired after every repaint (edits, Add, delete, paste, move-out, undo/redo, revert/reload). The panel now follows a MAT-file variable's edits, not only a reload.onReplacedis gone, becauseonChangedcovers it.writeUserFile, the safe write with its stamp from the write, as the binary dictionary editor does.backupId.ts(same format; old backup ids still restore). Its private copy is removed.diskFollow.readStamped/readForOpen, so the stat-before-read rule is written once.tableDispatch.dispatchCommonanswers what every table editor answers the same way: ready, select, navigate, requestMatrix, requestChildren, undo and redo. All four providers use it, each with its own handlers: the JSON view's ready ordering and native undo, MAT's annotator, and the read-only viewer with no undo/redo.test/messageDispatch.test.tsreads each provider's table and still fails if a provider drops a message, answers one twice, or a read-only view gains an editing message.Tests: unit 4332 passed; integration 425 passing / 2 pending, on this branch merged with main.