Vscode: Focus editor when using Find Widget

[jsunsawyer]

After typing in the search field, pressing enter, cmd + g, or cmd + shift +g should focus the current editor that is being searched.

Currently, the Find Widget keeps the focus, so the user is required to put the focus back in the editor before they can update any text.

With this change, users can always put the focus back in the editor with cmd + f.

[atiris]

I think the expected functionality of the Find Panel is not described in the User's Guide. So you can't tell if a particular Find Panel behavior is wrong or not.

The requirement to write basic rules on how the Find Panel working I entered here: Find Panel in the Guide. So far, I have no response whether this is a good idea or not. Also, some behaviors seem like a bug to me, but without Find panel definition I can't say for sure. I think they (vscode programmers) will recommend you using ESC :smile: which is not what I except like best practice of using Find panel.

In your case (and in ideal world) I would expect:

• ENTER => Finding next occurrence, Find panel has still focus. (working)
• SHIFT + ENTER => Finding previous occurrence, Find panel has still focus. (working)
• CTRL + ENTER => Silngle occurrence confirmation, document get focusing, Find panel is closed. (not working, it's more intuitive to me than using ESC)
• ALT + ENTER => All confirmation. All occurences are selected, cursor is multiplied, document has focus, Find panel is closed. (partially works, Find panel is not closed)

Anyway, I think it is first necessary to agree on the Find panel behavior and write these requirements into the user's guide.

[jsunsawyer]

Well, basically all I want is for my quick search (not the search in folder search) to focus the editor after a search is performed or any search related hotkey is used that is not intended to focus a part of the search form specifically.

It's easy enough to refocus the search pane if you need to edit your search.

Coming from Atom, I feel like I'm having to use my mouse or learn complex hotkeys to do anything basic.

If nothing else, simply giving us a way to customize this functionality would be super helpful.

[atiris]

OK, I understand, you need option to close the Find panel after searching (replace actual ENTER and ESC sequence only with ENTER). And I would like to describe the behavior of the Find panel, because now I do not know if the correct behavior of the Find Panel is to find and close panel (like you would - and the actual behavior is wrong) or now it is as designed.

[berliner]

Coming from a Textmate 2 and Sublime background, I definitely find it counter-intuitive that the focus is not on the editor after doing a search. When I search for something, then I generally want to interact with the found string, either copying it, deleting it, changing it, or whatever, but the place where I most definitely don't need to do any more work is in the search field. So having to hit ESC after searching, is adding a couple of hundreds of extra key hits per day to my workflow.

[atiris]

I created a request to discuss the functionality of the Find Panel Find panel documentation is missing. @berliner please, contribute also to that request, if you have a better view of how to design the entire Find Panel functionality...

For me, it is intuitive (Notepad ++ in Windows, Geany in Linux) that pressing Enter will find the next occurrence of the search term, but the panel will not close because I do not expect to find the one occurrence that I search for immediately. Therefore, it is more natural for me to go through the individual occurrences with Enter. The use of ESC to confirm selection is significantly non-intuitive. Since using ESC, I would expect to close the panel and return the original selection (not the last item found). I would expect something like CTRL + ENTER to confirm selected occurrence (like in ALT + ENTER for all occurrences is being used).

However, I understand that this proposal will not be too acceptable for you (as it will increase the number of keys you need to behave like the editors you mention).

[berliner]

@atiris Not sure that I will find the time to work on the proposal you linked too.

But some quick remarks anyway. In most editors you can use a different shortcut to loop through all found occurrences of a string, on a Mac it's usually CMD-g (and SHIFT-CMD-g for reverse loops). I have set this up in my vscode too for the shortcut editor.action.nextMatchFindAction, so this gives me your intended behaviour (looking for further occurrences because the one you're looking for is probably not the first one found). The main difference is that you can use that shortcut in the editor and the cursor automatically jumps to the next found match, enabling you to directly interact with the match.

If you look at bit at behaviours of search fields all over the web, you'll probably find that keeping the focus in the search bar is rather the exception than the rule. I don't mind this behaviour in word processors or excel-type programs, but code editors should focus on minimising key strokes.

The current behaviour feels in sync with how this is often implemented on Linux (no idea about Windows), but coming from an environment with a stronger emphasis on UX and workflows (as the Mac has been, though arguably in decline, bot of those points my personal view, let's not start a discussion about this ;)) it just doesn't seem like the best solution. TextMate really does an amazing job at this, if you get a chance, try it out for a little while.

[rebornix]

Thanks all for your contribution. I understand the ask for focusing the editor after searching but I don't think we are going to make the change considering how many users will be affected by that. With https://github.com/microsoft/vscode/pull/63176 merged and another shortcut CMD+G, you can search selections without losing focus and if you use the Find Widget to type in new queries, once the focus goes into the editor, you can use CMD+G to navigate in the editor.

[vscodebot[bot]]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[jsunsawyer]

What's the more common thing that users do next after searching using the find widget? That's what should drive this decision.

What does keeping the user focused on the find widget really offer? Let's say a user doesn't find what they're searching for and wants to search for something else. Does leaving them focused on the find widget save them any time? They need to clear out their previous search by either deleting their previous search with backspace, selecting all text then typing, or entering the find widget hotkey, which selects all the search text anyway.

Additionally, with the CMD+G functionality that was merged, you should consider how CMD+F behaves when initiating a search from highlighted text. Compared to only using CMD+G, users are now stuck in the find widget again, even after typing CMD+G.

It just feels clunky right now. If this isn't going to be addressed simply because people are used to its clunky behavior, an option for those who prefer that the editor is focused upon searching would be greatly appreciated.

[jsunsawyer]

@rebornix Seeing some of the features that were added in 1.40.0, I'm having a hard time understanding why improvements to the find widget are considered out-of-scope.

You introduced an option to set the background color of the active activity bar indicator. I use the find widget constantly.

Please consider re-opening this issue, as I don't believe that it should be marked as out-of-scope.

[francois-m]

Coming from Atom, I'm also disturbed by the search field's behavior. Everyone here would be happy with a preference for giving the focus to the editor after pressing Enter. The many users already used to ESC after search won't be affected, and the new ones -like me- will change the preference for more efficiency. Please.

[francois-m]

I finally found a solution for giving the focus back to the editor after search (Ctrl+F): just map the Enter/F3 keys to the "workbench.action.focusLastEditorGroup" command, which will occur in addition to the default mappings for "editor.action.nextMatchFindAction".

Add these mappings to your keybindings.json (edit it with command "Open Keyboard Shortcuts (JSON)":

{
    "key": "enter",
    "command": "workbench.action.focusLastEditorGroup",
    "when": "editorFocus && findInputFocussed"
},
{
    "key": "f3",
    "command": "workbench.action.focusLastEditorGroup",
    "when": "editorFocus && findInputFocussed"
}

This works well on v1.44.2