fix: newline style inheritance after clearing inline formatting (SD-2228)#2559
fix: newline style inheritance after clearing inline formatting (SD-2228)#2559caio-pizzol merged 10 commits intomainfrom
Conversation
…override When storedMarks is set to an empty array ([]), it represents an intentional user action to clear all formatting. Previously, the `|| null` coercion and falsy checks on storedMarks caused empty arrays to be treated the same as absent storedMarks, falling through to paragraph/style inheritance and re-applying formatting the user had explicitly removed. Switch from `||` to `??` and introduce a `hasStoredMarks` flag using strict null checks so that an empty array is respected as "no marks".
When a user applies formatting (e.g., bold) and then presses Enter to create a new paragraph, the storedMarks set by the formatting action were being overwritten by applyStyleMarks, which resolved style marks from the document's style hierarchy. This caused the user's explicit formatting choice to be lost on the new line. Capture storedMarks before style resolution and, when present, restore or retain them instead of replacing with style-resolved marks.
The run-management append-only plugins (calculateInlineRunProperties, cleanupEmptyRuns, wrapTextInRuns) emit follow-up transactions that rebuild run nodes and normalize selections. These transactions inadvertently clear storedMarks, discarding formatting the user had explicitly toggled before typing. Propagate the original storedMarks through each plugin's transaction so that explicit formatting state survives run restructuring.
…n has no formatting When pressing Enter at the end of a run that has no inline formatting, the new paragraph was inheriting the parent paragraph's runProperties (e.g., bold). This caused the new line to appear formatted even though the cursor was in an unformatted run. Extract a shared syncSplitParagraphRunProperties helper that either copies the current run's properties or explicitly removes them from the new paragraph attrs, ensuring the split paragraph only inherits formatting that the run actually carries.
Verify that pressing Enter at the end of a line where bold+italic was explicitly removed does not carry those marks into the new paragraph. Covers the full user flow: type formatted text, remove formatting from the end of the line, press Enter, and assert the new line is unformatted.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b5a23fb53b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
luccas-harbour
force-pushed
the
luccas/sd-2228-new-lines-style-inheritance
branch
from
183a375 to
e13def7
Compare
luccas-harbour
requested review from
VladaHarbour,
artem-harbour,
caio-pizzol,
harbournick and
tupizz
caio-pizzol
left a comment
caio-pizzol
left a comment
There was a problem hiding this comment.
@luccas-harbour looks good, approving.
i tested this locally — toggling bold off then pressing Enter works correctly in both cases (fresh typing and imported Word docs). also checked the exported .docx XML and the new paragraph comes out clean, no leftover bold.
two small suggestions inline — a duplicated helper and a possible behavior test for the import→edit path. nothing blocking.
|
🎉 This PR is included in vscode-ext v1.1.0-next.11 |
|
🎉 This PR is included in superdoc-cli v0.5.0-next.10 The release is available on GitHub release |
|
🎉 This PR is included in superdoc v1.24.0-next.10 The release is available on GitHub release |
|
🎉 This PR is included in superdoc-sdk v1.3.0-next.10 |
|
🎉 This PR is included in esign v2.2.0-next.3 The release is available on GitHub release |
|
🎉 This PR is included in template-builder v1.3.0-next.2 The release is available on GitHub release |
|
🎉 This PR is included in superdoc v1.24.0 The release is available on GitHub release |
|
🎉 This PR is included in superdoc-cli v0.5.0 The release is available on GitHub release |
|
🎉 This PR is included in superdoc-sdk v1.3.0 |
|
🎉 This PR is included in vscode-ext v2.2.0 |
2 participants
Summary
This PR fixes newline formatting inheritance around explicit formatting removal at a collapsed caret.
The main change is to treat explicit cursor formatting state as authoritative when splitting paragraphs. When the user removes bold/italic at the end of a formatted line and presses Enter, the new paragraph should no longer inherit the previous run’s inline formatting. This now works for both split paths: standard paragraph splits and run-to-paragraph splits.
What Changed
storedMarks = []in formatting-state resolution so cleared formatting is preserved at the caret instead of being rehydrated from inherited paragraph/run formatting.storedMarksthrough run-wrapping, run cleanup, and inline run-property recalculation so plugins do not accidentally lose the user’s explicit formatting state.splitParagraphRunProperties.jsand applied it to bothsplitBlock.jsandsplit-run.js.storedMarksWhy
Before this change, pressing Enter after clearing inline formatting at the end of a formatted line could still carry formatting into the next paragraph because the split logic and follow-up run plugins fell back to the previous run’s formatting instead of respecting explicit caret state.