Release Notes:

- Added/Fixed/Improved ...

Release Notes:

- N/A

Generated by 🚫 dangerJS against d335841

Thanks for this!

I'm not super happy with this living in the focused handler, but it does seem to work. There's an odd edge case:

• put cursor on line 1, /b to match something on line 2, click on line 3. click on a different pane. click the "x" in the search bar. The cursor will go back to line 1 not line 3.

I don't think that's a deal breaker per-se; but it's indicative of the structure of the code not quite matching the problem.

Do you have other ideas for how we could structure this to be less intrusive?

Thanks for the review!

I dug into the architecture to find a cleaner solution.

The Problem

My focused() approach doesn't distinguish between:

• Search bar dismissed → editor regains focus (should restore cursor)
• User clicked in editor while search open → editor regains focus (should NOT restore cursor)

Recommended Solution: Add Event::Dismissed to BufferSearchBar

This pattern already exists in ProjectSearchView which has ViewEvent::Dismiss. The implementation would be:

1. Add to buffer_search.rs:

pub enum Event {
    UpdateLocation,
    Dismissed,  // New
}

2. Emit in dismiss():

pub fn dismiss(&mut self, _: &Dismiss, window: &mut Window, cx: &mut Context<Self>) {
    self.dismissed = true;
    // ... existing code ...
    cx.emit(Event::Dismissed);  // New
}

3. In vim, subscribe when search starts:

// In search() when deploying search bar:
let subscription = cx.subscribe(&search_bar, |vim, _, event, cx| {
    if let search::buffer_search::Event::Dismissed = event {
        let prior_selections: Vec<_> = vim.search.prior_selections.drain(..).collect();
        if !prior_selections.is_empty() {
            vim.update_editor(cx, |_, editor, cx| {
                editor.change_selections(Default::default(), window, cx, |s| {
                    s.select_ranges(prior_selections);
                });
            });
        }
    }
});
// Store subscription in SearchState

Why This Is Better

1. Explicit event - Vim only acts on dismiss, not on every focus change
2. Follows existing patterns - ProjectSearchView already does this
3. No edge cases - If user clicks elsewhere before dismissing, that's a separate selection change; prior_selections are restored only on actual dismiss
4. Cleaner separation - Search bar owns the dismiss event, vim reacts to it

Alternative Considered

I also considered clearing prior_selections in local_selections_changed when user moves cursor while search is open. But this is fragile because activate_match also triggers SelectionsChanged { local: true }, so we'd need to track whether the editor had focus at the time of the change.

Would you prefer I implement the Event::Dismissed approach? I can update both the search crate and vim crate.

thanks. let's try that and see if it works.

Implemented the Event::Dismissed approach as discussed, with an important correction:

Clarification on the edge case: In my earlier comment, I incorrectly claimed that the Event::Dismissed approach would have "no edge cases." That was wrong—the edge case you identified (click on line 3 while search open, then dismiss → cursor incorrectly goes to line 1) would still occur with just the event subscription.

The fix now addresses this properly:

1. Event::Dismissed - Added to BufferSearchBar and emitted when search is dismissed. Vim subscribes to this and restores prior_selections if non-empty.

2. Edge case handling in focused() - When the editor gains focus while the search bar is still open (not dismissed), prior_selections is cleared. This handles the case where the user clicks in the editor before dismissing—they've explicitly navigated away, so we shouldn't restore to the original position.

This cleanly separates concerns:

• focused(): "User navigated while search open → clear saved position"
• Dismissed subscription: "Search dismissed → restore saved position (if any remain)"

Added a test that verifies the edge case: opening search, focusing editor while search is open, then dismissing—cursor stays at the match location rather than being restored.

All 456 vim tests pass.

Thanks