Skip to content

refactor(document)!: one way to edit a document - #839

Merged
andiwand merged 1 commit into
mainfrom
refactor/one-way-to-edit
Sep 6, 2026
Merged

refactor(document)!: one way to edit a document#839
andiwand merged 1 commit into
mainfrom
refactor/one-way-to-edit

Conversation

@andiwand

@andiwand andiwand commented Sep 6, 2026

Copy link
Copy Markdown
Member

🤖 Generated with Claude Code

PR 9 of the v7 API plan.
Stacked on #838.

What moves

html::edit(document, diff)Document::edit(operations).

It takes a Document, walks the element tree, and produces no html. The only
thing tying it to namespace html is that our browser-side JavaScript writes
its input. JNI had already worked this outjni_document.cpp carried the
comment:

odr::html::edit, but it belongs to Document

Named edit rather than the plan's apply, to sit beside is_editable and to
match where JNI put it. ObjC's HtmlTranslator.edit(document:diff:) moves onto
ODRDocument.edit(operations:) the same way, and java's Html.edit static —
which was a one-line forward to document.edit(diff) — goes.

What does not move, and why

Text::set_content stays. The plan had it removed as "the second road into
editing". Working through it, that was wrong, and I have amended the plan doc
in this PR rather than quietly dropping the item:

  • They are not one operation spelled twice. set_content edits a named element
    in process; edit replays a log a browser produced. Different callers.
  • It is mirrored in all three bindings (Text.setContent,
    set_content, setContent:) and exercised by the Swift suite. Removing it
    takes capability away.
  • A caller who wants to change one text run would have to assemble JSON.

The odr::open/DecodedFile duplication this series is about was one
implementation under two names. This is not that. What was actually wrong was
the filing, and that is what this PR fixes.

So the three "can I edit this?" answers also stay — FileTypeCapabilities::edit
(format-level), Document::is_editable(), Element::is_editable() answer
different questions at different altitudes.

Bindings

before after
Java Html.edit(document, diff) document.edit(diff)
Python pyodr.html.edit(document, diff) document.edit(diff)
ObjC HtmlTranslator.edit(document:diff:) Document.edit(operations:)
wasm unchanged surface, calls through Document

Verified

Full build; 57 Document*/*edit* gtests, 72 python tests, JNI junit all pass.
Apple (11 TUs) and wasm (6 TUs) syntax-checked with -Wall -Wextra -Werror.

Migration

html::edit(document, diff)  →  document.edit(diff)

@andiwand
andiwand force-pushed the feat/decode-options branch from 037532d to d4e5968 Compare September 6, 2026 14:04
Base automatically changed from feat/decode-options to main September 6, 2026 14:07
html::edit takes a Document and touches no html; the only thing tying it to
that namespace was that our browser-side JavaScript writes its input. It moves
to Document::edit, where jni had already put it - jni_document.cpp carried the
comment "odr::html::edit, but it belongs to Document" - and objc's
HtmlTranslator.edit follows it onto ODRDocument.

Text::set_content stays. The plan had it going as the second road into
editing, which was wrong: editing a named element in process and replaying a
log a browser produced are different operations, and it is mirrored in three
bindings and exercised by the swift suite. The plan is amended with why.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016hxDa2rev11eLUEJZJ5nmz
@andiwand
andiwand force-pushed the refactor/one-way-to-edit branch from 0b80ffd to 6a8c287 Compare September 6, 2026 14:12
@andiwand
andiwand merged commit be9ef44 into main Sep 6, 2026
30 checks passed
@andiwand
andiwand deleted the refactor/one-way-to-edit branch September 6, 2026 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant