Add search function within patch viewer

[roseoriorden]

Add a vim-like expression search /
Supports regex like vim and has the same n/N controls

Assisted-by: Claude Sonnet 4.5, Claude Code

[dceara]

Thanks @roseoriorden for this feature, I tried it locally and it seems to work quite nicely!

Here's some comments on the actual code from my side. Please take them with a grain of salt as it's the first time I really look closely at the leadlight code so some of them might be completely off.

Thanks,
Dumitru

[dceara]

Nit: Should all this search related state be part of a separate group of fields, lower. I mean, it applies to the compare mode too and that has its own separate section of fields.

[dceara]

I'm not sure I like the mixing of search logic with key handling. keys.go seems like the appropriate place to handle all input keys for all modes. Would it make sense to keep it like that?

[dceara]

searching is a bit misleading IMO. It actually is used to reflect the "the user is typing the search query" state. Only once the search is "committed" (enter is hit) we actually are in searching state.

[dceara]

Here, if the match is only on one side (left or right) but not on the other we'll try to highlight on both sides and fail for the side that doesn't have the match.

But does that mean that we'd also potentially scroll incorrectly? Shouldn't the searchMatches be part of the compareSide struct instead?

Which means, shouldn't we have a let's call it SearchMatcher struct, that stores all matches. And we could potentially use it in three places:

• for the viewportLines (in patch view mode)
• for the left lines (in compare view mode)
• for the right lines (in compare view mode)

Maybe that will also remove the need for the slightly unnatural if m.viewMode == viewCompare { checks in search.go, what do you think?

[igsilya]

Some LLM review comments:

Commit 1: 9314b07 — "tui: search: Add vim-like expression search /<expr>." (3 issues, medium)

1. \C always overrides \c — In parseVimSearchPattern, the \C check runs after \c, so \C always wins when both flags appear. Vim uses last-flag-wins semantics, so foo\C\c should be case-insensitive but isn't.
2. Compare view duplicate matches — updateCompareSearchMatches indexes both sides of a compare view with the same lineIdx, producing duplicate matches for identical lines. Pressing n visits the same visual line twice. Also, highlightLineIfMatched doesn't distinguish panels, so both sides show current-match highlighting simultaneously.
3. Stale searchMatches after content rebuild — switchToComment and the WindowSizeMsg handler rebuild viewport content without clearing or re-running search. Pressing n after navigating to a different comment or resizing jumps to stale line indices.

Commit 2: 0f38713 — "tui: search: Add search history." (2 issues, low)

1. N to recall last search navigates to first match — recallLastSearch() always sets searchIdx = 0, so pressing N (which should go backward) starts at the first match instead of the last.
2. Up arrow discards in-progress search text — Pressing up to browse history overwrites partially-typed input without saving it. Pressing down back to index -1 restores an empty string instead of the original partial text.

Commit 3: 4af6be2 — "tui: search: Make esc exit patch, q clear search then exit." (2 issues, low)

1. Duplicated viewport exit cleanup — The "q" and "esc" cases in both handleViewportKey and handleCompareKey contain identical 7-field cleanup code. Should be extracted to a helper to avoid divergence.
2. Typo in commit message — "serach" should be "search".

I didn't look too deep into the code myself, but one of the big things I tried to avoid in different places in leadlight is parsing and/or updating what was already rendered. This is fragile and hard to maintain. The search logic should be applied to the original text and then the rendering pass should already highlight the findings. This may require extra translation between original and rendered line indexes due to possible wrapping, but would solve a few problems like inability to find wrapped text or the need to re-apply the search and re-highlighting after resize or comment switching that the LLM review flagged above.