Land shared editor API primitives (getDocText, getParagraphs, applyEdit) - #554
Draft
kcarnold wants to merge 1 commit into
Draft
Land shared editor API primitives (getDocText, getParagraphs, applyEdit)#554kcarnold wants to merge 1 commit into
kcarnold wants to merge 1 commit into
Conversation
Land the host-agnostic document primitives that three separate feature branches (My Words v1, the My Words interaction design, and the voice spike) each independently re-added with identical shape. Landing the shared surface first stops those copies from drifting further and lets each feature branch shrink to just its feature logic on a common base. The new EditorAPI members: - getDocText(): full document text - getParagraphs(): document split into ordered paragraphs — the coordinate system the `view` tool numbers and paragraph-targeted inserts index into - applyEdit(edit: DocEdit): apply a structured str_replace/insert edit DocEdit is a host-agnostic edit type; each host lowers it to its own primitives. The Word implementation is the reviewed-text-aware version (reads tracked-changes "current" text via getReviewedText on WordApi 1.4, falling back to raw .text), so the AI never sees struck-through text. The Google Docs and standalone-editor hosts implement the read accessors and stub applyEdit until their bridges are wired up. Scoped deliberately to the primitives shared by all three branches: the My Words scratchpad persistence and the voice-only applySplice optimization stay with their feature branches. Added unit tests for the Google Docs read accessors and applyEdit stub. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XcidL4aeC5xV59XVXsipCF
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
2 participants
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.
Why
Three separate front-end branches from the "My Words" line of work each independently re-added the same additive editor API surface, with identical method signatures and JSDoc:
claude/confident-ride-7s1c3mclaude/mywords-interaction-design-cuvkl3claude/voice-native-conversation-research-k7uirlapplySplice?When N branches copy the same abstraction, it's infrastructure, not feature code. The copies have already begun to drift (the Word implementation gained tracked-changes/reviewed-text handling in the later branches). Landing the shared core on
mainnow stops that drift and lets each feature branch rebase down to just its feature logic.What this PR adds
Three new members on the host-agnostic
EditorAPIinterface, plus aDocEdittype:getDocText()— full document text (the corpus +viewtool).getParagraphs()— document split into ordered paragraphs; the coordinate system theviewtool numbers and paragraph-targeted inserts index into.applyEdit(edit: DocEdit)— apply a structuredstr_replace/insertedit. Each host lowersDocEditto its own primitives.Per host:
wordEditorAPI.ts) — full implementation. Uses the reviewed-text-aware version: reads tracked-changes "current" text viagetReviewedText(WordApi 1.4), falling back to raw.texton older hosts, so the AI never sees struck-through text. Track-Changes-awareapplyEditwith optional paragraph scoping.googleDocsEditorAPI.ts) — read accessors implemented via the existing Apps Script context bridge;applyEditstubbed (rejects) until the bridge is wired. The existing pull-based polling onmainis left untouched.editor/index.tsx) and context defaults (editorContext.tsx) — read accessors implemented;applyEditstubbed.Scope
Deliberately limited to the primitives shared by all three branches. Left with their feature branches:
loadScratchpad/saveScratchpad(My Words persistence)applySplice?and the internaldelete_paragraph/ParagraphSplicetypes (voice-only splice optimization)Tests
Added unit tests for the Google Docs read accessors and the
applyEditstub. Full suite: 40/40 passing;tsc --noEmitclean.Follow-up
Once this lands, #499 and #506 rebase onto it and shrink to their feature logic (My Words UI; voice spike).
🤖 Generated with Claude Code
https://claude.ai/code/session_01XcidL4aeC5xV59XVXsipCF
Generated by Claude Code