Take the newline with the paragraph it belongs to - #57
Merged
Conversation
Every paragraph-level delete stopped one character short, so each replaced or removed paragraph left an empty one behind. That blanket -1 was a workaround for a restriction that applies in exactly two places: the newline before a table, table of contents or section break, and the last newline of the body. Deletes are now exact, shortened only at those boundaries. Where a run does keep its newline, the text inserted in its place drops its own trailing newline -- the surviving one terminates the last inserted paragraph, and a second is what showed as a blank line. A paragraph immediately before a kept table still cannot be removed: Google refuses that newline unless the table goes too, and the table is what a comment-preserving sync exists to protect. Closes #56 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Every replaced or removed paragraph left its trailing newline behind as an
empty paragraph.
diffOpsToRequestssubtracted 1 from the end of everyparagraph-level delete — a blanket workaround for a restriction that
applies in exactly two places:
Deletes are now exact, shortened only at those boundaries. Where a run
does keep its newline, the inserted text drops its own trailing newline —
the surviving one terminates the last inserted paragraph, and the second
is what showed as a blank line.
GDocsStructuralElementgainstableOfContents. The app never writesone, but a user's document may already have it and it carries a table's
restrictions.
Verification
Two tests, both watched failing first, both asserting the document that
results from applying the batch sequentially rather than the ranges
emitted:
expected 'Keep\n\nAlso keep\n' to be 'Keep\nAlso keep\n'— a paragraphremoved between two others.
ZZZZ\nYYYY\n<table>\n<table>\n, with no blank after the new content.One existing test asserted the old behaviour outright (
endIndex15rather than 16 for a deleted paragraph). It encoded the artefact, so it
was updated rather than worked around.
pnpm test1035 passed / 62 files · typecheck clean · lint clean.Known limit
A paragraph immediately before a table the sync is keeping cannot be
removed — its newline is the one Google refuses to delete, and taking the
table with it is exactly what a comment-preserving sync must not do. A
rewrite whose new content has nothing to put there leaves one empty
paragraph in front of each such table.
Closes #56
🤖 Generated with Claude Code