* markdown: fix: route undo and redo to the document history
The Agents window Markdown editor attaches an EditContext, so the browser
keeps no native undo history and the Cmd+Z / Cmd+Shift+Z chords never
reached VS Code. Wire them to the backing TextDocument's own history:
- editor.ts: pass a `historyStrategy` to `EditorController` that posts
`{ type: 'history', command }` to the extension. `record` is omitted so
the TextDocument stays the single source of truth (no second local stack
that would drift from the Edit menu, dirty state and hot exit).
- markdownEditorProvider.ts: run the built-in `undo`/`redo` command; the
active custom editor input scopes it to the resource's IUndoRedoService.
- editor.ts: apply host `update` via `replaceSourceText` instead of
`sourceText.set`, so the caret is mapped through the change (e.g. after an
undo shrinks the document) and stale pending-paragraph state is cleared.
Depends on the @vscode/markdown-editor API from microsoft/vscode-packages#189;
the pinned version must be bumped once that is published.
Fixesmicrosoft/vscode#327535
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b5b60dce-b175-4fe6-b2b5-d18a229c9929
* markdown: chore: bump @vscode/markdown-editor to 0.0.2-40
Pick up the published `@vscode/markdown-editor` release that ships the
`IHistoryStrategy` / `EditorControllerOptions.historyStrategy` and
`EditorModel.replaceSourceText` APIs (microsoft/vscode-packages#189) the
undo/redo integration depends on. Dependency set is unchanged from
0.0.2-26; lockfile integrity matches the published tarball.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b5b60dce-b175-4fe6-b2b5-d18a229c9929
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b5b60dce-b175-4fe6-b2b5-d18a229c9929
* adds proposed createQuickDiffInformation API, adopts it in markdown editor.
* Extends textEditorDiffInformation proposal instead of having new quickDiff proposal
Our current implementation has some bugs that can hide changes. However even after fixing these, I'm not 100% confident a unexpected change wont sneak through. Best to make users aware of this while also trying to prevent this
- Use `frontmatter` (one word)
- Align `Show source` icon and text with the reopen with
- Make the `Open preview` in explorer use `reopen with` instead so you can nicely toggle the opened preview
This makes scroll sync faster by using a broadcast channel instead of the normal vscode webview api. This means the two webviews can communicate with each other directly instead of having to go through the extension host and renderer each time
This adds a propose api for computing the diff between two files. Custom diff editors can use this to make sure they have the same diffs that VS Code would use in it's built-in diff editor
Two regressions from the merge of #287050:
1. preview.ts: The merge retained `this.#isScrolling = false` inside
the early-return guard of `scrollTo()`, which was intentionally
removed in the original PR. This resets the timer-based flag on
the very first forward-sync call, allowing subsequent editor scroll
events to re-trigger forward sync while reverse sync is in
progress, causing the editor to jump back up.
2. index.ts: The PR converted `onUpdateView` from a decrement-counter
to a timer-based approach but left initialization and resize
handlers still using `scrollDisabledCount += 1` without a
corresponding timer reset. The old scroll handler decremented the
counter naturally; the new handler only returns early. As a result,
after page load `scrollDisabledCount` stays at 1 indefinitely,
blocking all preview-to-editor sync until the user scrolls the
editor once.
Fixes:
- Remove the erroneous `this.#isScrolling = false` from scrollTo()
- Apply the same timer-reset pattern (200ms) to initialization and
resize handlers so scrollDisabledCount is always auto-cleared
Fixes#307762