{{ message }}
Repository navigation
fix(muya): highlight regexp newline search matches (#3261) - #5650
Merged
Merged
Conversation
A regexp `\n` search found its matches — the find bar counted them — but drew nothing, because the soft/hard line-break renderers never applied the search highlight. A match on a line break can't be wrapped like ordinary text: the `\n` must stay a bare text node or the line stops breaking, and a background on an inline box whose only content is a forced break paints nothing. So render an empty highlight band just before the break, giving the match a visible end-of-line marker and leaving the line breaks intact.
Jocs
changed the title
\n search matches (#3261)
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The in-flow highlight band can wrap onto an extra visual line and alter document layout.
1 open finding
What changed in this PR
Fixes missing search highlights for regex newline matches in Muya while preserving line breaks.
Changes:
- Adds highlight bands for soft and hard line breaks.
- Preserves raw newline text during rendering.
- Adds unit and browser regression coverage.
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Copilot review: the band was an in-flow box with ~4px width, so a line that already filled the content width wrapped it — and the text after it — onto a row of its own. The band is now out of flow, positioned against the line-break span; the hard-break band sits before the hanging trailing spaces so it does not revoke the hang (#2094). The new E2E case measures row geometry, which the earlier `textContent` check missed. Also trims the comments this PR added to the ones the code cannot state.
Out of flow the inactive band is blockified, and `.mu-selection` carried no height of its own — it took it from the line box — so the non-active `\n` matches collapsed to a zero-height, invisible box. Pin the band height the way the active `.mu-highlight` already does, and assert both bands have a non-zero box in the E2E case.
Match how the other renderer helpers are wired (`this.highlight`, `this.backlashInToken`): a default-exported module registered in the `inlineSyntaxRenderer` map, instead of a named export called with `.call`.
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
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 #3261
Summary
A regexp
\nsearch found its matches — the find bar counted them (1/4) — but drew no highlight: muya's soft and hard line-break renderers never applied the search highlight.A match on a line break can't be wrapped like ordinary text. The
\nmust stay a bare text node or the line stops breaking, and a background on an inline box whose only content is a forced break paints nothing. So the line-break renderers now emit an empty highlight band just before the break, giving\nmatches the end-of-line marker VS Code draws while leaving the line breaks intact.Type of change
Test plan
New tests added (or explain why not needed)
Manually tested on:
Unit:
search.spec.tsasserts a regexp\nsearch bands every soft and hard line break and that the\ntext (hence the line split) survives;softLineBreak.spec.tsasserts the emitted band shape.E2E:
search-replace.spec.tsverifies in a real browser that both breaks are drawn and the content stays on three rows.pnpm -C packages/muya exec vitest run— 2431 passing;lint/lint:typesclean.Notes for reviewers [optional]
Paragraph breaks (separate blocks) carry no
\nin the model, so\nstill does not match across blocks — only line breaks inside a block, which is what #3261 reports.By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.