Fyi, it does not work. I get this error when opening Finda on macOS Ventura 13.0 (22A380):
"This version of Finda (629.0.0+df7956) is not compatible with your operating system version (22.1.0). Press Enter to download the latest version or Command+ to quit."
EDIT: e-mailed the Developer, beta release coming tomorrow...
I continue to not understand this -- The Everything app was capable of instant search on Windows in like 2008, and yet on modern devices, with SSDs, far more RAM, and faster CPUs, I have to wait a good 2-3s for results to appear.
How did one dev managed to achieve what, apparently, no corporate entity ever has?
sometimes I think MSFT should buy Everything and replace Windows search with it. There are some plugins that use it for other file managers.
But then again, they will almost certainly screw it up, given that Windows Search still can't search my start menu reliably without pauses. And their history with acquisitions and integrating tech isn't very good.
Things like that infuriate me and make me want to throw my laptop out of the window. There's no excuse for the start menu search not being instantaneous, but Windows isn't the only offender. Searching for an app on Android is also slow.
With Windows, it is death by a thousand paper cuts. With Linux, you might get your arm chopped off while getting every device (or sleep) to work flawlessly, but once it works, it stays working. And small things like search work like you expect them to.
I actually solved that by using the native macOS fsevents API which can watch the whole filesystem for changes, and I can instantly update the SQLite db I use for the index through that.
The problem is actually enumerating and searching the whole database, that's the slow part. Right now I have over 5 million rows in it and passing the SELECT results to fzf is the slowest part, taking a few seconds at least on an M1 Max.
I'm not sure how Everything presented the results so fast, with metadata and everything.
The fsevents part is interesting, didn't know that!
To your point regarding the slowness - in that case it's not really acting as an index though, is it, if you're scanning the whole list and passing it to fzf?
A proper fuzzy text search index (I think elastic and similar engines have these built-in) should yield orders of magnitude better performance.
Yes, you're right. I did try Meilisearch for this but I wanted close-to-instant Smith-Waterman fuzzy searching which is why I settled on FZF.
In the end I might have to reimplement that in Swift with an always cached index and native Spotlight like search bar to really make this as easy to use as I want.
It's not practical to reach for the browser or Terminal to do this search.
I wrote my own solution using fd + sqlite + fzf but it's nowhere as fast as Everything, and it also requires me to focus the Terminal to use it.