I don't think this is the behavior we want here. We should be focusing the search editor first, as that needs to be populated either way. What we should instead consider is having the opening replace action toggling focus between the search and replace editors if either of them is currently focused

I don't think this is the behavior we want here. We should be focusing the search editor first, as that needs to be populated either way. What we should instead consider is having the opening replace action toggling focus between the search and replace editors if either of them is currently focused

I understand your suggestion, but my original thought was to optimize for the specific case where a user has already made a selection and triggers a replace, in that case user is almost always looking to immediately type into the replace field. Currently the extra tab navigation to get to the replace field feels like a bit extra step which in my opinion is poor UX.

For context thats how VSCode handles this specific case.

Ah right, with a selection that would make sense, then we should only make it do that in that case though. If I understand your change correctly here this will always focus the replace editor

Yes currently it always focuses the replace field. I'll have a look into it.

I split this into two commits: first tries using query_suggestion().is_some() to detect selection for replace-focus. That turned out to conflate real selections with cursor-word seeding, so the follow-up commit adds has_non_empty_selection for SearchableItem and switches the focus logic to use that instead. So it now reflects the actual selection

I think that's it.

can you rebase on top of main once more? I think the CI step is bugged on the branch base you are on