"Tab" for next item in search results

[MaxHasBeenUsed]

Is your feature request related to a problem? Please describe.

Can only go through items by arrow keys

Describe the solution you'd like

Press "Tab" key for next item, "Shift + Tab" for previous. Like in PowerToys Run and Listary

[JohnTheGr8]

Hey, thank you for your feedback.

I suppose that what you want is to be able to navigate items with just your left hand on the keyboard.

The problem is, Flow already uses Tab as a mechanism for auto-completion. I'm afraid this doesn't leave any reasonable left-hand keys to use for the functionality you want... 🤷‍♂️

[Garulf]

We chose tab to mimic behavior found in console shells like BASH, ZSH, and Powershell.

Perhaps we could look into allowing this key to be customized?

[JohnTheGr8]

imo complicating things by making this customizable would not be justified here...

(if your right hand is not on the keyboard, it's probably on the mouse, and you can use that to navigate)

[MaxHasBeenUsed]

Thanks for your quick responses!

We chose tab to mimic behavior found in console shells like BASH, ZSH, and Powershell.
Perhaps we could look into allowing this key to be customized?

I use those tools as well, and see complete sense in "tab for auto complete". But for me it would be nice to have the option to make it work otherwise, since I basically use Flow as a launcher and barely need a auto complete feature. Also if I'm not wrong, "tab for navigation" is the default behavior in Listary and PowerToys Run. It would be easier for switching.

imo complicating things by making this customizable would not be justified here...

It could be confusing but Flow already allows people to change "Preview Hotkey" (similar to "Navigation Hotkey" or "Tab
Key Behavior") and "Open Result Modifier Key" (also a great feature). Maybe a third one wouldn't hurt?

Btw I'm actually a right-handed. But from the time I added Microsoft Japanese IME (which uses tab to navigate) for language learning purposes, it just makes so much sense to me that I just can't go back.

[VictoriousRaptor]

It could be confusing but Flow already allows people to change "Preview Hotkey" (similar to "Navigation Hotkey" or "Tab
Key Behavior") and "Open Result Modifier Key" (also a great feature). Maybe a third one wouldn't hurt?

I think "Tab Key Behavior" is the right way if we decide to implement such a feature. We barely have no keys for a new hotkey.

(if your right hand is not on the keyboard, it's probably on the mouse, and you can use that to navigate)

We still need to move right hand to touch arrow keys for navigation. Though open result modifier is surely better for instantly activating results.

[JamesNZL]

Transferring my comment from #2182—

I second this idea; I seem to find myself wishing for this ability every couple days.

Have we thought about using Alt + Tab as the hotkey (it is possible to intercept this while Flow is open?)

I'd argue that a launcher isn't really an application that you Alt + Tab away from in the traditional sense (and the launcher just closes itself anyway), so I think that intercepting the Windows hotkey probably isn't a UX problem.

[jjw24]

From what I have read in issue 2182 and here, seems those that request for tab to go next result don't need the autocomplete feature. Perhaps VictoriousRaptor's idea for a "Tab Key Behaviour" is a good choice- customise it to allow the switch between either tab next or autocomplete.

Although, let's say once you have tabbed to go to the result you want, what's the hand action to activate the result? Use right hand to press enter or use left hand to press open result modifier?

I am also still on the fence about the benefits of tab to go next as you still end up using your right hand, awkwardly moving to the right with your left or work your fingers for the modifier key presses.

[JamesNZL]

seems those that request for tab to go next result don't need the autocomplete feature

Not true for me; I'd want to keep Tab for autocomplete, and have some other way to cycle through the results.

Although, let's say once you have tabbed to go to the result you want, what's the hand action to activate the result? Use right hand to press enter or use left hand to press open result modifier?

This is only if autocomplete isn't the desired action.
Take the following example:

1. I type tgl for the default hotkeys.

   

2. I want to cycle through the results to reports, which I currently have to use the arrow keys for. This cycles through the results, without auto-filling the query.

   

3. Once I have highlighted reports, I hit Tab to autocomplete tgl reports, which moves to the next plugin state.

   

This repeats, all the way to the end state of tgl reports week projects, with only Tab autocompletes and no Enters.

[jjw24]

Going to convert this to discussion until we can come up with a good solution.

[MaxHasBeenUsed]

I am also still on the fence about the benefits of tab to go next as you still end up using your right hand, awkwardly moving to the right with your left or work your fingers for the modifier key presses.

If I'm getting it right, most of us here just prefer Tab to Arrow Keys for navigation. It doesn't mean all the actions must be done by the left hand.

It seems to me that the main obstacle we have here is how to conserve navigation AND autocomplete feature at the same time, as JamesNZL required. So only allowing customisation on Tab Key Behavior is probably not the perfect solution, since it's bound to make users choose between the two.

So I'm thinking about:

Tab for next item, → for autocomplete.

Inspiration was from PowerShell, which guesses your follow-up input based on recent activities, and allows → to accept the guess. Besides, this is basically a mirror to "Arrow for next, Tab for autocomplete". Maybe allow users to choose from this two sets?

[JamesNZL]

At least for me, this wouldn't really solve anything—it'd just make autocomplete (still my predominant action over next result) way harder if I switched to the other set.

Also, → is already used by Flow to go to the context menu, so this doesn't solve the hotkey-collision problem.

[JamesNZL]

Another idea, if Alt+Tab doesn't work—result modifier (ie Ctrl, Alt) + w and s.

<ResultModifier>+w to move up (like the up arrow), <ResultModifier>+s to move down (like the down arrow).

Thoughts?

[JamesNZL]

Flow.Launcher/Flow.Launcher/MainWindow.xaml

Line 59 in 0047d8a

Command="{Binding SelectNextItemCommand}"

I've just taken a look at the source code—this already exists...

Ctrl+n and Ctrl+j go to the next result, Ctrl+p and Ctrl+k go to the previous result...

I'll open a PR when I have a chance to add Ctrl+w and Ctrl+s to this list of bindings as I feel they are easier to use when you only have one hand, but it looks like no real business logic needs to change to implement what I'm after.

Wow, there are so many cool bindings I never knew about...

[onesounds]

I'm late to the party on this discussion, but I think the bottom line is that we need to have the following requirements.

1. previous/next functionality should be available with tab/shift+tab
2. there should also be an autocomplete shortcut
3. the right arrow should remain as a context menu.
4. there should be an option to keep autocomplete as it is for existing users who were using it as TAB

The rationale for this is as follows

• TAB and SHIFT+TAB are commonly used shortcuts for toggling selections.
• While James' PR has the advantage of being left-handed, it is not an appropriate solution to the original proposal because it is inconvenient for users who are used to using LISTARY or POWERTOY.

There are ways to make it possible to customize the shortcuts for each function, but in any case, we need to provide a default shortcut that we set up. I think there are two things we need to decide.

1. Do we want TAB as an autocomplete on first install?

• I'm curious what others think. I'm against it. I think TAB/SHIFT+TAB should be used for previous/next selection.

2. so what should be the default autocomplete shortcut?

• I don't know this part, what shortcuts are you using in other launchers, consoles, etc.?

In my opinion, once the default autocomplete shortcut is decided, then we can provide two settings. For example, let's say the autocomplete has determined CTRL+TAB.

On first install.

1. prev/next: tab / shift+tab
2. autocomplete : ctrl+tab

Setup for legacy users

1. prev/next : ctrl+w/ctrl+s
2. autocomplete : tab

@JamesNZL We will hold off on applying the 2190 PR until we have a conclusion on this issue. Please understand. Thanks.

[JohnTheGr8]

Do we want TAB as an autocomplete on first install?

Yes from me, Tab is a very natural autocomplete shortcut for anyone that spends enough time in a terminal. ctrl+tab is a strange alternative.

How about we have a couple of "shortcut profiles" that users can choose from, which can also be configurable from the initial setup guide. One of the profiles can include our current shortcuts for up/down/autocomplete, another one being a "listary / powertoys style" choice of shortcuts.

Also I'm not a big fan of the idea of changing the default shortcuts and having "legacy users", backwards compatibility code etc

[onesounds]

I get it. I'm not necessarily advocating changing the default either. The two settings I'm suggesting are the same as the profile you're talking about. I like to organize it like this

• Terminal type (default on first install)

1. autocomplete : tab
2. prev/next : ctrl+w, ctrl+s (or something different?)

• Windows Type

1. autocomplete : ?
2. prev/next : tab/shift+tab

[Garulf]

I think tab for selection choice makes a lot of sense.

Tab selection could be hard coded and we could give the user a choice of hotkey to invoke autocomplete.

[Garulf]

The fish shell has a neat little auto suggestion system that you invoke with → (Right Arrow key). This feels very natural and intuitive.

Here's an example:

Capture.44.mp4

[MaxHasBeenUsed]

It is already mentioned earlier.

[MaxHasBeenUsed]

Allow me to wrap up the wrap up, basically we have come down to 2 solutions here:

1. Add entries to let users set their own key bindings of related features.
2. Create sets of key bindings and let users to choose.

The first one is clearly more free for users, since it allows total customization, but I'm afraid it breaks the easy-to-use experience Flow Launcher has.

Whereas the second one is simple on the users side, it needs proper discussion on how the binding sets should look like.

[MaxHasBeenUsed]

I really want this to work out, so I'm gonna try to get through all of what we've discussed about the binding sets as clear and thorough as possible.

Before all, I'd like to reassure that we all agree using Tab for navigating through results is not just "for left-handed", but a common behavior used in similar projects and many other situations. So what @JamesNZL suggests (Shift+W/Shift+S) is not actually what we're talking about here.

But if you dig the idea, you can make it work now by simply using PowerToys or other programs to remap Shift+W/Shift+S to Up/Dn arrow keys in Flow Launcher.

Back on track. First, if Tab/Shift+Tab is used to navigate, we need another hotkey for auto complete. Which is now triggered by Tab/Shift+Tab.

Then, As mentioned by me and @Garulf suggests, Right arrow key -> could serve as the hotkey for auto complete. This is inspired by PowerShell and Fish Shell.

Then, @JamesNZL points out that -> is also already used by Flow Launcher to open context menu. This is where it gets a little complicated, but I'm thinking we could probably get away with just overwrite it, because Flow also has Shift+Enter to open to context menu, which is again, also a common behavior in many other situations where Shift+Enter means "Run with toggles/options".

So I to make my proposal easy to digest:

Key-bind Sets	Tab/Shift+Tab	Up/Dn	Right	Shift+Enter
1	auto complete	navigate	context menu	context menu
2	navigate	navigate	auto complete	context menu