{{ message }}
Repository navigation
fix(muya): keep a hard line break's glyph on the line it ends (#2094) - #5556
Merged
Merged
Conversation
Preserved trailing spaces hang over the right margin only while nothing follows them on the line. The `↩` marker was generated after them, so it both revoked the hang and asked for width a full line had none of: a line whose text reached the margin pushed the marker alone onto the next line, costing a whole line of vertical space. Generate it as an out-of-flow `::before` instead — ahead of the spaces in the inline flow, painted past them at `inset-inline-start: 100%`. The spaces keep hanging, the text wraps exactly as it would with no marker shown, and the marker stays where it was. 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.
Closes #2094.
The bug
A line ending in two spaces (a hard line break) shows a
↩marker. When theline's text reaches the right margin, the marker wraps onto the next line by
itself, so the paragraph grows by a whole line of empty-looking space. The
reporter's example still reproduces in the current engine: the text sits on
line 1,
↩alone on line 2, and the text after the break on line 3.Why
.mu-hard-line-break-spaceholds the two literal spaces and generated themarker as its
::after. Underwhite-space: pre-wrap, preserved trailingspaces hang over the margin — but only while nothing follows them on the
line. Generated content after them revokes the hang and needs width of its
own, so the break opportunity at the spaces is taken and the marker lands
alone on the next line.
Measured in Chromium against the real engine: the failure covers an ~18px band
of column widths (the width of the two spaces plus the marker), at every one of
which the paragraph is one line taller than the same text with a soft break.
Taking the marker out of flow as an
::afteris not enough — itsstatic position still sits after the spaces, so ~half the band remains. The
marker has to be generated ahead of the spaces to leave them last on the
line.
The fix
Generate the marker as an out-of-flow
::beforeand paint it past the spaceswith
inset-inline-start: 100%(logical, so RTL is unchanged — verified). Thespaces keep hanging, the text wraps exactly as it would with no marker shown,
and the marker renders where it always did. A marker no longer inflates the
line box either, so a hard break now costs exactly what a soft break costs.
Tests
packages/muya/e2e/tests/inline/hard-line-break-wrap-2094.spec.tssweeps thetext column across 400 widths and asserts, at every one:
(the issue's stated expectation), and
line differs from the soft-break control's).
Both fail on
develop(the first over an 18px band) and pass here. Alsoverified in the packaged app: the same sweep over
--editor-area-widthfailsbefore the change and passes after it.
🤖 Generated with Claude Code