Add (fuzzy) search

[max-sixty]

Is your feature suggestion related to a problem? Please describe.
I was directed here from this discussion. I've been a heavy user and fan of Contexts. Unfortunately it's no longer in development (though works fine atm).

To quote that discussion:

One of my favorite features is quick switching by holding down Caps/Esc and typing some of the Application / Window name. It'll be fuzzy matched and when releasing Caps/Esc, the selected window will be focused. So if you know the window you want to switch to, it's extremely fast.

And mindfulhack responded:

The dev is currently extraordinarily dedicated to responding to tickets and is in heavy development.
I've already helped out and contributed a bit. Recommend to start Github issues for any gripes right away.

To the extent that's something you think would fit into the vision of this app, I find it invaluable.

[lwouis]

Hi @max-sixty! Thanks for sharing this suggestion!

This is a great idea. I had a lot I wanted to discuss, so I made a video response. Please check it out

[max-sixty]

This is amazing! I'm watching now. I already really appreciate the response!

[max-sixty]

This is really one of the most impressive interactions I've had in OSS, I really appreciate it.

A couple of small replies after watching the video:

• Thanks for showing those customizations, I copied them
• Your quick read on Contexts very much resonates. Both the parts you liked — the memory of searches — and the parts you found over-complicated — too many options, too many states
• Definitely no need for arrows keys within the search — generally it's <5 letters. Backspace is more than enough

Thanks again!

[nfekete]

I love this idea a lot. Two things popped to my mind while watching the video.

1. If you were to implement it without a special trigger shortcut, just by having the user start typing in order to narrow the list of windows by fuzzy match, that would conflict with the current shortcuts used to close windows, minimize/unminimize window, quit app, hide/show app. These shortcuts are really useful, I use them quite often so I think they are really worth keeping. Maybe another (optional) modifier key could be used for either of these functions. You could create settings for having another modifier key for the fuzzy match filter and another additional modifier key for the window/app shortcuts. You could make any of these optional, so as no additional modifier key would be required for that particular function. Just need to make sure they are not conflicting with each other. You can't have both fuzzy match filter and window/app shortcuts with the same/no modifier key.
2. An advanced version of this would be to filter not just for app names/window titles, but tab names as well. You could search for Chrome/Firefox/Safari, etc. tabs directly from within AltTab. Maybe it could be done with some sort of plugin architecture. I realize this is a bit stretching the purpose of AltTab and I am not sure it could be integrated into AltTab in a nice seamless way. But I thought it wouldn't hurt throwing in the idea.

[max-sixty]

If you were to implement it without a special trigger shortcut, just by having the user start typing in order to narrow the list of windows by fuzzy match, that would conflict with the current shortcuts used to close windows,

Yes. Contexts has this by holding Caps while typing (or in my case Esc is mapped to the caps key). So that doesn't interfere with Alt+Tab. An it's only one key to hold down — harder to type characters if you're already holding two keys.

[lwouis]

@nfekete

1. Yes indeed there needs to be a solution to allow shortcuts and search to co-exist. You mention adding an optional modifier for each. I like the optionality of it. People who prefer one modality or the other can have the one they like without modifier and put the other on a modifier. We could imagine a key trigger instead of a modifier also. I'm thinking that maybe a key trigger would be nicer because on key press we could switch to search mode, and the user could release their hands from the keyboard keys and search without having to hold anything. The key could be any combination of modifier(s) and/or key btw.

2. There is a ticket in that general area already: Show selected tab favicon on browser windows #527. I think for search in tabs to be realized, we would need first to get be able to list tabs as individual windows, which we do for standard tabs already through a preference. Of course custom tabs are way messier as we have to write specific code for each browser, and it will break anytime they change their UI slightly.

[nfekete]

@lwouis

I think for search in tabs to be realized, we would need first to get be able to list tabs as individual windows, which we do for standard tabs already through a preference. Of course custom tabs are way messier as we have to write specific code for each browser, and it will break anytime they change their UI slightly.

I don't know, maybe that's a bit of a stretch to have all the browser tabs content rendered as thumbnails, I often find myself having hundreds of open browser tabs. I think that would not scale, not from performance point of view, and neither from UX side. Still it would be great to have some function where I could very quickly narrow down a browser tab from many open browser tabs and switch to that window and the tab inside it directly, even if I have another app focused at the moment. There is a Quick Tabs (github) Chrome extension where you can select a Chrome tab with fuzzy search, but it's not the greatest UX. I still have to focus a random Chrome window first before I am able to activate the Quick Tabs search to switch to the tab I'm looking for.

[lwouis]

I'm not sure how the UX for 100 open tabs works. I type "and" which is contained in, let's say 50 out of 100 tabs. What do we show in AltTab at this point? We have to show the 50 tabs i feel to be useful, no? Or some custom UI on all the Chrome window, like just the number 50?

Can you please describe the UI you have in mind? What i had in mind was simply filtering the thumbnails shown, which implies that before the search, all windows and tabs are visible

[probablykasper]

The way I have Contexts set up is to start fuzzy search immediately when I press a key, so for example if I want to switch to Discord I do cmd + (tab, then D). If that behavior could be replicated in AltTab, that's what I would go for

[cocoonkid]

That would be so amazing! Was about to open a feature request when I happily noticed it is already being discussed.

I work on arch simultaneously and use rofi (https://github.com/davatorium/rofi)

The it works there is that I setup cmd + w and it will show me a fuzzy search for all open windows at the top and all installed apps below these. (window and drun mix mode).

That enables really fast app / context switching.

Adding this to alt-tab would be amazing (even tho that'd need a list view ).

I just deleted hyperswitch and the above would allow me to get rid of alfred as it only always opens apps...

THANKS for this great piece of software.

EDIT: found this which offers a similar option. https://manytricks.com/witch/

[gkpln3]

Would definitely love to have this feature, if anyone is working on it I'd love to help :)

[maxwellhibbert]

Was just about to request the same thing. Something like the Contexts app did.

[muescha]

Given that I don't utilize basic keys for certain triggers:

I would appreciate an option wherein every key (without a modifier) serves as a search term.

[timkgh]

@lwouis

We could imagine a key trigger instead of a modifier also. I'm thinking that maybe a key trigger would be nicer because on key press we could switch to search mode, and the user could release their hands from the keyboard keys and search without having to hold anything. The key could be any combination of modifier(s) and/or key btw.

+1. Alt-Tab, while holding down Alt hit / and enter search mode.

[tylercollier]

@lwouis Just checking if you're waiting on anything from "us" (users) to work on this? I see you're directing people to this issue from other issues, but it's unclear to me if you're still waiting on feedback before implementing. Btw thanks for working on AltTab!

[lwouis]

Hi,

I'm closing duplicates like I do for all tickets. This helps keep this issue tracker healthy.

I'm doing this alone. It takes most of my time maintaining this project. I wish I could get help. Please see the pinned issue #1179

---

Regarding next steps for this ticket, I think we need 2 things:

1. Someone to draft functional specs

   • Draw some mocks to share the basic ideas of the UX
   • What would the UI elements be? Anything actionable with the mouse or trackpad? Would we highlight text fragments matching the search in the titles?
   • What would the keyboard interactions be? How to deal with conflicts with shortcuts?
   • How to operate this when the modifier key is held versus when it's released?
   • How would the fuzzyness in the search->results work? What's algo should we use? How would we handle highlighting in the titles since it wouldn't always be 1:1 with the search
   • How would unicode be handled (e.g. European accents, Chinese, Korean, Japanese, Hindu, Emojis, etc)?
   • Would the feature be for all users, or an opt-in for people who want it? What would be the UX to opt in or out?
   • More details: would the search remain between invocations, or would it reset? Would we have a history of the last N searches?

2. Someone to share a PR

From experience, I think both the specs and the implementation would be lots of work. Especially the specs/designs.

Please remember pinned issue #1179. It would be great if someone here would step up and work on this issue and push it to the finish line 🥇

Thank you

[matgeroe]

I'm currently working on a project where I have to use about 10 vscode instances simultaneously. As all these windows more or less look the same visually, it is hard to swap to the correct window when tabbing, I have configured Alt-Tab to display window titles, which helps, but I am, as you pointed out in your video response, reading, instead of visually searching for the correct window. I am hopeful that being able to type a bit of the window name, will at least cut down on the amount of windows that I need to mentally filter, to end up at the correct one.

Considering the above context, I'd like to kick-off the discussion by answering your questions as follows:

• UI elements: maintain the appearance as is, based on the users preferences for visual style. After invoking Alt-Tab via shortcut e.g. option+tab, release the tab, whilst keeping the alt depressed. You should be able to type some characters which will effectively filter the displayed windows, now only displaying the matching ones. Now the usual controls may be used to cycle trough the filter subset. Releasing Alt as well, will result in selecting that tab (or nothing according to user setting)
  I think, there is no need for being able to correct your input, hitting esc, will as per usual dismiss the pop without changing windows, Alt-Tab may then be re-engaged. Both cancelling (esc) and switching windows should reset the search state.
• To prevent collisions with existing shortcuts while active, those for closing windows etc. I'd say an extra modifier can be introduced, it's behaviour can be set in the settings. It either, activates 'search mode' or activates 'shortcuts when active'
• By filtering the resultset I believe there is no need for highlighting titles.
• I'd consider the 'shortcuts when active' to be more advanced than searching. Therefore requiring the extra modifier for the advanced behaviour seems reasonable to me. I am biased as I would use search, and am not using the 'shortcuts when active'. Something is to be said for not breaking the ux with an update, however.
• unicode, can only speak to european accents, I would not use those when searching. search input e would just match é in a window title. For characters that need a combo themselves to be typed, maybe those can be wildcarded?
• Search history, I would suggest collecting this information, as you identified in the video, being able to sort windows based on which window was last activated for a given search result, seems like a clever feature. I don't think the search state should persist. More likely then not, when searching, I am targetting a window I haven't accessed in a while. When activating Alt-Tab a second time, I am likely just switching back to the previous window rather than continuing my search

regarding #1179: Not a osx developer, but I'll take a look this weekend to see if I can make sense of the project

[lwouis]

Thank you @matgeroe

If I understand correctly, you suggest no UI whatsoever. So there is no way to know that the view is filtered, or by which characters it is filtered, by looking at the UI? I think that could be frustrating if the user makes a typo and doesn't understand why the window is not showing. I think some kind of UI would clarify what's going on.

To prevent collisions with existing shortcuts while active, those for closing windows etc. I'd say an extra modifier can be introduced, it's behaviour can be set in the settings. It either, activates 'search mode' or activates 'shortcuts when active'

The idea of a mode is the way to go, I think. I think I've seen a tool do this previously. I suggest we type "s" or "f", as a new While opened shortcut to search. So you would alt > tab > "s" > type your search string. Typing "s" would move into search-mode, in which While opened shortcuts are ignored.

[matgeroe]

If I understand correctly, you suggest no UI whatsoever. So there is no way to know that the view is filtered, or by which characters it is filtered, by looking at the UI? I think that could be frustrating if the user makes a typo and doesn't understand why the window is not showing. I think some kind of UI would clarify what's going on.

Not quite what I meant, although not very clearly communicated, I was hinting at the lack of editing options being acceptable, just displaying the current search as readonly.

Consider this the default case, the current as is UI:

Then with search mode activated:

Notice how irrelevant windows have been filtered out of the displayed selection and an element has appear atop the usual window grid, displaying the active search query.

The idea of a mode is the way to go, I think. I think I've seen a tool do this previously. I suggest we type "s" or "f", as a new While opened shortcut to search. So you would alt > tab > "s" > type your search string. Typing "s" would move into search-mode, in which While opened shortcuts are ignored.

I had in mind a spotlight-esque behaviour, where upon activating the tool with the shortcut it is immediately ready to receive input, thereby saving an extra keystroke.
However seeing this feature as just another while active shortcut does make sense, and I'd image it simplifies the implementation, therefore I concur.