Proposal: Shifting how search works in PT Run

[crutkas]

Description of the new feature / enhancement

I'm proposing we shift on PT Run search works by maybe default, maybe permanent.

• Program search + Windows settings are only global searches by default
  • Items that don't infer direct hits like Folder search could as well since they require things like c:\ to be invoked.
• everything else is triggered via plugin activation command

Why:

• Some plugins have latency we just can't get around. Anything that does a web search would also hit this. Since we wait for all results to come back since we have combined results, the slowest result impacts everything.
  • if we didn't, the UX would 'pop' and rearrange itself as results flowed in causing misclicks
• Simplifies weighting. Which is more important, a document named "Visual Studio" or the Application "Visual Studio"
• As a searching person, you have context of what you want. If you want a doc, you know it is a doc. if you want a shell command, you know it.

Scenario when this would be used?

quick app trigger, more relevant results

Supporting information

Issues like #12968 have always been a constant issue against PT Run.

[Aaron-Junker]

Good idea, but only if we don't modify already existing settings.

[crutkas]

@Aaron-Junker, we cannot promise this won't be a breaking behavior change.

[HadziJo]

Please restore the key combination "ALT + SPACE" to access the currently in focus window's menu (Max, Min, Restore, Move, Size). Most any other combination NOT used by Windows Explorer by default for "PT Search" is fine. It is not a good practice to have an add-on that creates side-effects to existing key-combinations.
thank you
joe.

[crutkas]

@HadziJo you can go into settings and change your default. that request is outside this proposal as well.

[Chaphasilor]

• As a searching person, you have context of what you want. If you want a doc, you know it is a doc. if you want a shell command, you know it.

I have some doubts about this one. The problems I see are the following:

• Sometimes you really don't know the type of result you're searching for, or can't be bothered to think about it. There are still instances of programs not showing up in PT Run, when the program's shortcut file does
• I can already see myself putting in a quick calculation, realizing that it only searches programs & settings by default, and having to jump to the start of the query to add the plugin activation command. Same applies for opening websites, searching files, etc.

I do have an idea on how to work around this issue though:

There could be a search "mode", like the one you have when ctrl + f-ing in text editors like VS Code, Visual Studio, etc.
Here's what I'm talking about:

The mode could be modified using alt + <mode>, to switch between the default (only programs & settings) or full (search using all enabled plugins, like it is right now).
I'm sure there would even be a way to design this is a way that lets the user have finer, keyboard-based control over the active plugins, for example:

• input any plugin activation command in a separate field instead of in front of the query
• enable/disable plugins based on their index (alt + 1, alt + 2, etc.)
• allow plugin activation commands as suffixes at the end of the query (my query %, my workspace {, ...)

Generally, I do understand the motivation behind limiting which plugins are active by default, but I think it's very important to think about this extensively and come up with a well-designed solution that doesn't make the search any less useful!

[crutkas]

Maybe an idea is we do enable a full global mode vs speed. Or full global is enabled via ? Foo

[Chaphasilor]

Was thinking about this, using ? or !. Still doesn't solve the "problem" of having to jump back to the start of the query after not finding what one was looking for :)

[crutkas]

@Chaphasilor typically you know what you want. If it is an app, the thought here is you would just type. Else, use the global command / targeted action command but would be slower results due to non deterministic results.

Right now we have a single list of results, if we don’t return in a single set, you will see popping and have possible mis-clicks when stuff sorts based on updated results. if there was a plugin that queried a web server but took 1 second, any result at best right now would be one second.

[crutkas]

@Chaphasilor can you be more targeted in your statement. Would like to better understand also

what you outline would still exist if you mistyped or tried to find a file with the wrong term

[Chaphasilor]

What I'm talking about is that there should be a (better) way to enable "global" search after having done a search already. So that if you type xyz and notice that your desired result is not included (because the plugin isn't active), you can use a shortcut or a suffix to re-search with all plugins, and don't have to move your cursor to the start of the input field.
It's about quickly and easily changing the active plugins (e.g. default, global, or a custom combination) at any time, no matter where your cursor currently is.

The search bar is pretty wide and could easily fit a couple controls for this. The screenshot of the search box I posted really is the best example of what I'm talking about; instead of the Aa (case-sensitive) mode, we would have a "global" mode that you could toggle via the keyboard or a shortcut.
This also has the added benefit of users not having to memorize any special characters, because they can see (and click) the option at any time :)

And yeah sure, if you mistype your query, you get the wrong results, but that's not my point. I'm just talking about easily switching between different search modes.

[stefansjfw]

Just thinking out loud.. What if we introduce an option of showing results grouped by plugin? Maybe in addition to all results as it is now. This would require some nice UI update to support switching the shown results to per-plugin ..

[crutkas]

@stefansjfw you'd get UX popping

[stefnotch]

In some cases, it would be possible to:

1. wait slightly longer until the user has entered a few characters
2. based on those characters, figure out which plugins could be relevant (e.g. htt means that the URL plugin is going to be relevant. Meanwhile typing 3+ is a strong indication of the user wanting to do a calculation.)
3. include placeholders in the search results for those plugins
4. once those plugins have completed, fill in the placeholders

Would have the advantage of making PowerToys seem super smart. But it's entirely possible that that "smartness" could end up getting in the way.

[Jeffri-Eduzo]

I have a bug in PT run. When the search bar comes I can't type into the input field right away. I have to manually select the field then I'm typing. Before it wasn't the case. Version. 0.55.1

[Jay-o-Way]

The word suffix brought the idea of a parameter to my mind, just like after a executable. Something like "search word /all"?