Skip to content

[shared] Fix Find highlights going stale after edits (#264)#293

Merged
Shpigford merged 3 commits into
mainfrom
fix-find-highlights-stale
Apr 29, 2026
Merged

[shared] Fix Find highlights going stale after edits (#264)#293
Shpigford merged 3 commits into
mainfrom
fix-find-highlights-stale

Conversation

@Shpigford

Copy link
Copy Markdown
Owner

Summary

  • Find highlights no longer drift when the user edits the document (the original #264 symptom). Mac uses NSLayoutManager temporary attributes — Apple's documented pattern for transient UI highlights — so painting never touches NSTextStorage and never collides with ==highlight== markdown backgrounds; iOS re-runs the syntax highlighter on apply/clear (UIKit's NSLayoutManager has no temp-attribute API).
  • Highlights are cleared immediately on any character edit; the find bar surfaces a resultsAreStale flag so the user knows to retype, and ⌘G / Find Next re-runs the search when matches were cleared.
  • Fixed an @Published willSet timing bug where the Combine sink for state.$query re-read findState.query and got the OLD value, causing every search to run one keystroke behind — performFind now takes the new query as a parameter.
  • Also clears find state on external text replacement (file load / revert) so cached match ranges can't survive a different document.

Fixes #264

Test plan

  • ⌘F, search a word repeated multiple times → all matches highlight
  • Edit text near an earlier match → all highlights clear immediately, resultsAreStale shows in find bar
  • ⌘G / Find Next after edit → re-runs the search against the updated document
  • Search a word inside ==highlighted== markdown, then close Find → yellow markdown background is intact
  • Type a query a character at a time → highlight always matches the current find-bar text (not one keystroke behind)
  • iOS: same scenarios in TestFlight Debug build

Clear find highlights on edit and surface a "stale" state in the find bar
so the user knows to retype to refresh. ⌘G / Find Next re-runs the search
when matches were cleared. Mac uses layout-manager temporary attributes so
find backgrounds don't collide with `==highlight==` syntax; iOS keys
removal on the find color value for the same reason. Also clears matches
on external text replacement (file load/revert).
Two bugs surfaced after the initial #264 fix landed. Mac's `@Published.$query`
sink re-read `findState.query` when it fired, but `@Published` publishes in
willSet — so the read returned the OLD value and every search ran one keystroke
behind; pass `newQuery` from the sink directly into `performFind`. Both
platforms also painted find color onto `NSTextStorage`, which overwrote any
`==highlight==` markdown background it landed on; Mac now uses
`NSLayoutManager.addTemporaryAttribute` (Apple's pattern for transient UI
highlights, doesn't touch storage), and iOS re-runs the syntax highlighter
on apply/clear since UIKit's `NSLayoutManager` has no temp-attribute API.
@Shpigford
Shpigford merged commit 7ff8f39 into main Apr 29, 2026
4 checks passed
@Shpigford
Shpigford deleted the fix-find-highlights-stale branch April 29, 2026 12:37
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 Highlights Become Incorrect After Editing Text

1 participant