Prefer paths which end with the search term

[nexus.chebykin]

Say I have an IntelliJ project in folder C:\Users\Nexus\MyFavoriteProject. That means that a C:\Users\Nexus\MyFavoriteProject\.idea folder is also created. When I search for "MyFav" and the ordering is set to "Run Count descending", the first result is the more nested .idea folder, followed by the project folder itself.

This is fine for the Everything app itself, but when used in combination with Everything Powertoys it becomes slightly annoying. It feels fairly reasonable to prefer the less nested options.

The question is, then, how are results sorted when they are tied by the main criteria, and whether this could be configured.

Currently, I can think of two workarounds:
- If the results are tied, then sort by folder depth. This, however, breaks on the following example: C:\Users\Nexus\RL, searching for "RL" because I also have C:\JupyterLab.
- Appending star: "MyFav*" does the job by forcing this search term to be the last one. It feels like adding a star to the last search term generally does what the user wants when searching for folders, and does not affect searching for files (assuming you write the terms in the same order that they appear in the path). It also solves the RL problem.

Appending star does create its own problems: when searching for folder "AAABBBCCC" and only remembering the "BBB" part you will no longer be able to find it, unless querying for "*BBB". This is obviously a trade-off that not every user is willing to make. I, however, am. Would it be possible to add a toggle to always append a star to the last search term? (Of course, this would require understanding what qualifies for the "last search term", since we do not want to literally append a star to the search string)

[NotNull]

In the provided examples, these searches should give theexpected results when Match Path is disabled.
(Menu => Search => Match Path. Or double-click PATH in the statusbar for the same effect.)

[nexus.chebykin]

Okay, I believe this is not the best solution:

1) I want to keep "match path" turned on, since it is more powerful, and, if my proposal was to be implemented, would basically supercede the disabled "match path". It is also not practical to toggle match path on and off with EverythingPowerToys, which is IMHO a more convenient interface for most of the searches.

2) Correct me if I'm wrong, but pretty much nobody wants the current default behavior of "match path". If I typed "folder", I am probably not looking for "folder/sub". Once again, it would be somewhat solved if secondary sorting options were configurable (and maybe they are, and I simply missed it).

3) Disabling "match path" still does not solve the RL problem. I would argue someone typing "RL" most likely prefers the folder "RL" itself, then "RL_blah_blah" and just then "helloRLbye". I would also argue that in the last case they would probably recognize that the folder name does not start with "RL" and would prepend a star to the search.

4) Finally, I propose this to be a toggle, so it wouldn't harm any of the current users. (although I believe it would do what the user wants more often than the current default)

[horst.epp]

Okay, I believe this is not the best solution:

1) I want to keep "match path" turned on, since it is more powerful, and, if my proposal was to be implemented, would basically supercede the disabled "match path". It is also not practical to toggle match path on and off with EverythingPowerToys, which is IMHO a more convenient interface for most of the searches.

2) Correct me if I'm wrong, but pretty much nobody wants the current default behavior of "match path". If I typed "folder", I am probably not looking for "folder/sub". Once again, it would be somewhat solved if secondary sorting options were configurable (and maybe they are, and I simply missed it).

3) Disabling "match path" still does not solve the RL problem. I would argue someone typing "RL" most likely prefers the folder "RL" itself, then "RL_blah_blah" and just then "helloRLbye". I would also argue that in the last case they would probably recognize that the folder name does not start with "RL" and would prepend a star to the search.

4) Finally, I propose this to be a toggle, so it wouldn't harm any of the current users. (although I believe it would do what the user wants more often than the current default)

You assume wrongly what others prefer.
For myself, the default with Match Path off is what I need most of the time.
For the other cases, it's just a click on Everything toolbar before I enter a search.

[nexus.chebykin]

You assume wrongly what others prefer.

Which point exactly do you disagree with?

For the other cases, it's just a click on Everything toolbar before I enter a search.

Can you elaborate, please? Do you mean right click on the bottom bar and click "match path"?

This change also would not affect those already satisfied with their experience, while bringing a QoL improvement to others.

[horst.epp]

You assume wrongly what others prefer.

Which point exactly do you disagree with?

For the other cases, it's just a click on Everything toolbar before I enter a search.

Can you elaborate, please? Do you mean right click on the bottom bar and click "match path"?

This change also would not affect those already satisfied with their experience, while bringing a QoL improvement to others.

1. Your assumption about the Match Path

2. Using the Everything Toolbar need no click on any Everything button bar.
It's done above the search field of the Toolbar.

Screenshot - 03.04.2025 , 12_35_40.png

[nexus.chebykin]

Your assumption about the Match Path

Which assumption? You can quote parts of the message too
By definition "Match path" is more powerful. I would also be surprised if you want .idea being the first result of the search for MyFavoriteProject.

As for the Everything toolbar, I am glad that you enjoy it. That being said, if you are satisfied with the current state of `Everything`, it should not prohibit adding new features, should it?

[horst.epp]

As for the Everything toolbar, I am glad that you enjoy it. That being said, if you are satisfied with the current state of `Everything`, it should not prohibit adding new features, should it?

Of course, no problem to add new features, we are in Alpha state.
Your assumption that enabling Match Path would be a better way is just wrong.
It's only better for the way you personally search with Everything, not in general.

[therube]

(I'll suppose this is what we're talking about, Everything for PowerToys Run ?)

[horst.epp]

(I'll suppose this is what we're talking about, Everything for PowerToys Run ?)

I tried it and removed it from my PowerToys settings.
There is no benefit compared to using the Everything Toolbar.

[NotNull]

The jury is still out on percentages of people having Match Path enabled/disabled by default.
Even among the "vocal minority" on these forums it is split. And who knows how the silent majority uses it ...

Anyway, will move this discussion to the Suggestions forum, where it belongs.
Thank you for your suggestion and explaining it!


But fwiw, I have Match Path disabled most of the time. Too many results otherwise.
If I need results fro the path, adding something like \win (for results fro the \windows folder) or \*something*\ (if something is in the path) is enough for my -- admitted simple -- needs.