Just regular fuzzy finding is the most common. For example, to attach a file instead of faffing around clicking in the open dialog, I type into fluent search(a frontend to everything) and it enters it in the current context i.e the open dialog.
It has a few other qualifiers, like big: huge: etc to search large files. Same way with time etc.
Rarely when you need it you prefix with regex: and you get everything you need.
It's very useful that both everything and fluent search integrate into explorer in that if you right click on the search result you get the same context menu as you would in explorer. Drag drop works, etc,. The issue with every other tool in every other OS is the lack of this feature. You basically have a virtual fully featured directory for every search result, simply cannot beat that.
I have some use scenario (finding backlinks in a folder containing thousands of markdown files) where this method fits perfectly and returns results instantaneously (even ripgrep takes a second or two to find all the backlinks as it doesn't use an index).
Unfortunately the text snippet showing the context that you get in explorer is not easily retrievable via Windows API. I made a suggestion [1] to the author and he seems open to implement it.
I use astrogrep for searching file contents on windows, it's pretty fast. Not nearly as fast as everything but I guess that's the nature of searching full contents. Just restrict by file type and filter out node modules and it's fast enough
It has a few other qualifiers, like big: huge: etc to search large files. Same way with time etc.
Rarely when you need it you prefix with regex: and you get everything you need.
It's very useful that both everything and fluent search integrate into explorer in that if you right click on the search result you get the same context menu as you would in explorer. Drag drop works, etc,. The issue with every other tool in every other OS is the lack of this feature. You basically have a virtual fully featured directory for every search result, simply cannot beat that.