Add Cmd+A support in search bar to select all text

[belkocik]

Title: Add Cmd+A support in search bar to select all text

Description:

Currently, when typing in the AltTab search bar (press 's' to search), there's no way to quickly select all text using the standard macOS keyboard shortcut Cmd+A. This makes it cumbersome to clear and retype search queries, especially when switching search terms quickly.

Expected behavior:
Pressing Cmd+A in the search bar should select all text, following standard macOS text editing conventions.

Current workaround:
Users must manually select text with mouse

Benefits:

• Consistency with macOS native text field behavior
• Faster workflow when changing search queries
• Better keyboard-only user experience
• Aligns with other standard text editing shortcuts (Cmd+C, Cmd+V, Cmd+X)

Use case:
When quickly switching between different searches (e.g., searching for "Chrome" then immediately wanting to search for "Terminal"), Cmd+A followed by typing would be much faster than backspacing or mouse selection.

[lwouis]

Hi,

thank you for opening this issue.

This is a tricky topic. We've created a custom search experience that sits in the middle of a very custom interactive environment. What I mean here is that the user has to do a shortcut just to reach the UI. So they may still have their finger like their command key pressed for example as they engage with the search and then the second layer which is the trickiest is that in AlTab the user can remap shortcuts to anything they want. For example, they may change the AlTab shortcut to command tab or to command D or command C, whatever they like. So that means we can have conflict with normal macOS behavior. For example, if the user has set command-c to show the UI, then of course command-c is not meant to copy-paste anymore. And that's their choice. We cannot prevent it. Some people have very specific workflows they like.

So what we could do is we could maybe check is there a bound shortcut in LTAB and if not then we do the normal behavior but then that's inconsistent across users it will work for some not work for others.

Another thing to keep in mind is that a lot of people rebind the option key to the command key because they want to do command tab on the Mac. They're used to that. That's the default app switcher experience. So for all these people, if they start going into the command C, command V, command A, Command X territory now already half the shortcut is is bound to AlTab and possibly conflicting. So yeah, I'm just explaining the reason why we preposefully disabled a lot of the native behavior of the search box. And I'm not saying I have the answers for what's what's best out there. I will need some time to think about it.

Another thing to keep in mind is that we benchmarked a bit how this type of custom search is done in other apps. We looked at uh IntelliJ for example uh context like some other apps that where you can type and then the search is is in the background in a way you're searching and you're doing more stuff at the same time and we went onto the current design where for example the arrow keys it's very interesting the way we have overridden the default behavior to move the cursor to instead move the the selection. We think that's a that's what people would expect and it's most useful case.

Another thing to keep in mind, uh you you have the log search mode, so if you press space, instead of adding a space to the query, which you don't really need, spaces all taken into account so, you can just type text, it's gonna work. You can type multiple words without space, they're gonna match. If you press space, it's gonna lock the search, and then you get full control, you get back kind of you can press your shortcut stuff like that because yeah that's another thing to keep in mind if the user has a shortcut let's say they press m to minimize a window so let's say command m you minimize then if they want to type some text in the box that involves the letter M, we certainly don't want to trigger the shortcut, we actually want to type M in the box. So we actually ignore the shortcuts while the search is ongoing unless they lock using space and if they lock they they their intention is clearly now to stop typing and start doing shortcuts so now we listen to the shortcuts so here is a window into the complexity of that feature and I'm gonna think about it and if you have kind of refined thought on this and you think we could approach it certain ways please let me know.

I'll keep the ticket open to have the conversation open

Thank you