Repository: PowerToys
Issue: [Run] A "Favorites" system, for increasing the item weight of specific search results
Labels: Idea-Enhancement,Product-PowerToys Run,Needs-Triage,Run-Plugin

### Description of the new feature / enhancement

The current automatic system is supposed to increase priority of previously selected results, however this rarely works as intended in my [and many others experience](https://github.com/search?q=repo%3Amicrosoft%2FPowerToys+run+sort+order&type=issues). 
The bug that made me think of this was #31157. Regardless of how many times I open Spotify, 'Mobile Hotspot' stays the top suggestion - even with item weight 0 for Windows Settings.

Improvements to search rankings would be welcome, but I want to suggest a "Favorites" system as a more reliable method to increase the item weight/priority of any given search result. Favorites could either be assigned the max item weight, or "max item weight +1" (atleast figuratively) so they always appear first. I'd prefer the latter.

I can think of two feasible UI implementations for manual use:

- A: The classic 'star' icon. It could be placed to the left of the results, or as another context button to the right, but perhaps furthest to the right and a bit visually distinct. 

- B: Right clicking a search result could open a context menu with "Add to favorites", "Prioritize in future searches" or similar. This would be less intrusive, but would perhaps be underused, since PT Run is about speed and convenience anyways. On the other hand, it would be a good place for another feature: hide/decrease priority in future searches.

- I'd prefer the former. But regardless of UI: also add the option to "Automatically add selected result to favorites after X times", with default ~5. Unfavoring something should prevent it from happening again. As this deals with specific results and not plugins this wouldn't solve the complex issue of search rank priority, but it would be a workaround for some use cases. But even if search rankings were perfect I'm sure some would still like this feature: I know I would.

- Also: A hotkey to favorite/unfavorite the current selection, and/or Shift+Enter to "Open and add to favorites"

I know the part below makes this a pretty unreasonable sized suggestion, but I'd just like to outline my entire idea as I think it makes more sense this way. 
<details>
<summary>Future features: Aliases, groups and a "Run Manager"</summary>

For starters, I'd "only" want the Run Manager to do this:

- Manually add/remove favorites.

- Add aliases for favorites. 

- Add multiple favorites into "Run groups" assigned to a keyword/group alias. 

So a Run group could be 'games' with game .exe's, 'synthpresets' for the spread-out folders of different VST-synths (iykyk), or 'assignments' with some .pdfs and docx's. Perhaps mixing files with directories could get messy, but other than that.

Sure start menu folders are a thing, but this would provide quick & easy mouseless interactions, no visual or functional limit for the amount (or size) of groups, and all of Run's current and possible future functionality. 

Bonus if this would work for folder navigation and search. E.g. give the alias "Projects" to a folder, and the input `Projects/2024/April` navigates to that folder. Search with `Documents/Articles/*.pdf`, etc.

And as if I haven't gone a bit overboard already.. With plugin support for actions & interactions, you could effectively make Run a sort of "search terminal" with the features and naming conventions of your choosing. `ra vsc+cmd` (runs both as admin), `copy folderA/*.docx folderB`, execute `backup "Documents", >cmd shutdown -s -t "900"` with the alias "goodnight", or what have you.

### Scenario when this would be used?

What makes Run great is quick and easy access to the stuff you're looking for. Favorites would be an improvement to this, and Groups would expand it from "perfect when you know what you want" to "also great when you only know *kinda* what you want".

For some use cases, "Auto add to favorites" fixes a long-standing issue with a system that will always be hard to perfect.

### Supporting information

Currently, previous queries are stored in "\PowerToys\PowerToys Run\Settings\UserSelectedRecord.json", with frequently used items given a higher weight in future results. Supposedly, at least, because this doesn't always work as intended, and seemingly never has (e.g. #9098)