Skip to content

fix: match Find queries across a soft line break (fixes #1590) - #1592

Open
xiaolai wants to merge 1 commit into
mainfrom
fix/issue-1590-find-cant-match-text-across-a-soft-line
Open

xiaolai wants to merge 1 commit into
mainfrom
fix/issue-1590-find-cant-match-text-across-a-soft-line

Conversation

@xiaolai

@xiaolai xiaolai commented Oct 21, 2026 •

Copy link
Copy Markdown
Owner

Summary

In WYSIWYG mode, Find could not match text across a soft line break: the break is stored as "\n" inside the paragraph's text, but it renders as a space, so a query such as a chat assis found nothing. Outside code blocks, the text being searched now reads each soft break as a space. The swap is one character for one, so match positions stay exact for highlighting, navigation, Replace and Replace All.

Policy Gates (Required)

  • This PR is single-focus (one issue, one problem, one objective).
  • This PR includes 100% test coverage for changed behavior and changed code paths.
  • If this is a bug fix, the linked issue contains detailed reproduction context.

Linked Issue

Type of Change

  • Bug fix
  • Feature
  • Docs
  • Refactor
  • Test-only
  • Other

What Changed

  • src/plugins/search/findMatches.ts: soft breaks are treated as spaces in prose before matching; code blocks (spec.code) keep "\n". The header's key decisions are updated.
  • src/plugins/search/findMatches.test.ts: 7 regression tests — literal, whole-word and regex queries; a break inside bold text; Replace consuming the break; code-block newlines unaffected; hard breaks still not matching; a document parsed through the real markdown pipeline with the StarterKit schema (fails without the fix, passes with it).
  • Behaviour note: in regex mode, \n no longer matches a soft break in prose (it reads as a space, as the user sees it); \s and a literal space both match it. Source mode is unchanged: there the newline is a visible line break.
  • Codex audit: 1 iteration, zero findings.

Validation

  • I ran pnpm check:all locally.
  • I added or updated tests to fully cover behavior changes.
  • I manually verified critical flows. (Not run in the live app; covered by the real-pipeline test.)

UI Evidence (if applicable)

Not applicable — no visible UI change.

PR Checklist

  • The PR avoids unrelated refactors or cleanup.
  • The issue context is clear (linked issue or explanation above).
  • Docs/changelog were updated if behavior or usage changed. (The Search & Replace guide makes no claim about line breaks; nothing to update.)
  • I am ready to address review feedback.

A soft line break is stored as "\n" inside a paragraph's text but renders
as a space, so a query such as "a chat assis" never matched text that
wrapped onto the next source line. Outside code blocks the aggregated
text now reads each soft break as a space before matching. The swap is
one character for one, so match offsets still map onto document
positions for decorations and replace. Code blocks keep "\n", where it
is a real line break.

Regression tests cover literal, whole-word and regex queries, a break
inside marked text, replace consuming the break, code blocks, hard
breaks, and a document parsed through the real markdown pipeline.

Closes #1590

This branch has not been deployed

No deployments
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.

[Bug] Find can't match text across a soft line break

1 participant