Change the default shortcut of Search history navigation to up and down arrows

[sandy081]

Change the default shortcut of Search history navigation to up and down arrows

[davisein]

+1 to this change.
In addition, it would be good to have support for cmd+Z or ctrl+Z for undo in the text box.
I thought it was not supported and was looking for it until I found #5508.

[petersladek]

Totally agree. I just had to google to find out Alt+Up/Down works, not intuitive at all. Just copy the experience from sublime text please - including combo selection, autocomplete for folders etc.

[leegee]

Almost switched back to Sublime to get this feature, thought I'd file a feature request to have Search History added, got here.

[DanOlivier]

Uh... Where is the search history for the other fields (files to include and exclude, replacement strings)?
Oh, here it is: #20547.

[campbells]

+1

Went on the same little goose chase as others to get here. Expected is tabbing for field navigation, up/down for history nav (cf to current line start/end).

[colin-home]

+1, I didn't realize the search history even existed, since the arrow keys didn't scroll through entries. Even better would be a visible drop-down to pick from, as in feature request #23099.

[ssbarnea]

I agree on that, I was using this on Atom for years and assumed vscode is missing the feature! Please fix it ASAP and allow us to use UP and DOWN, without having to press any modificators.

[leegee]

How many votes do we need to get this addressed?

[sandy081]

Now you can navigate the history in all input boxes in the following places using Up and Down arrows

• Search
• Editor Find
• Problems
• Terminal Find

One side affect of this change is that, you can no longer navigate among input boxes in Search view using up and down arrows. But this (navigating) is made consistent with editor find widget.

[ssbarnea]

@sandy081 This is great. Your remark reminded me about one issue related to navigation between search dialog fields. There are 3-4 buttons that change the search behavior (case, regex, word-match) and those are listed just after the search text. meaning that pressing tab to go to the next field will select them, which is very unlikely what the user may to.

User may want to switch between "search", "files to include" and "files to exclude" using a single TAB and SHIFT-TAB for reverse. I think that the buttons should not be included in the list, or if included they should not be between those 3 major fields.

If needed, I could provide screenshot, just let me know. I think it should be very easy to discover.

[sandy081]

@ssbarnea Currently tab and shift tab navigates between search and replace boxes just like editor find widget. I have not included pattern boxes.

[twstddev]

@sandy081 I actually have bindings assigned to the nextInputBox and previousInputBox commands. However, I used them to navigate from search input to search results and back :)
Do you think it's still possible to achieve this functionality with the currently exposed commands or with the current api available to extensions?

[sandy081]

search.focus.nextInputBox and search.focus.previousInputBox commands exist but without any default keybinding. If you have customised a keybinding for those, they will continue to work.

@ssbarnea You can associate keybindings to above commands to get current navigation with your keybinding.

@roblourens FYI

[twstddev]

@sandy081 thank you for the reply.
Unfortunately, I get following error "command 'search.focus.nextInputBox' not found".
Anyway, I was able to get the desired behaviour by remapping my keybinding to list.focusFirst command :)

[sandy081]

Changed my mind about defaults. New defaults are cmd+up and cmd+down for navigating among input boxes and results.

[sandy081]

@twstddev I did the change to bring them back today. So they will be available in insiders on Monday.

[twstddev]

@sandy081 that's awesome. Thanks a lot 👍