Hi all, been working on this for a while. I love fzf, but I wanted to a more robust way to use it in my own applications than calling it a shell, and Skim wasn't quite what I was looking for. I'd say it's close to feature-parity with fzf, in addition to being toml-configurable, and supporting a unique command-line syntax (which in my opinion is quite nice -- especially when binding shell-scripts where escaping special characters can get quite tricky, I'd be curious to know what you feel about it!), as well as a couple of features that fzf doesn't have, such as better support for cycling between multiple preview panes and support for priority-aware result sorting (i.e.: determining an item's resulting rank based on the incoming rank as well as similarity to the query: useful for something like frecency search).

I know that fzf is an entrenched tool (and for good reason), but personally, I believe matchmaker, being comparable in _most_ aspects, offers a few wins that make it a compelling alternative. One of my hopes is that the robust support for configuration enables a more robust method of developing and sharing useful fzf-like command-line interfaces for everything from git to docker to file navigation -- just copy a couple lines to your shell startup, or a single script to your PATH to get a full application with _your_ keybinds, _your_ preferred UI, and _your_ custom actions.

But my main motive for this project has always been using it as a library: if you like matchmaker, keep your eyes peeled as I have a few interesting TUIs I have built using it lined up for release in the coming weeks :)

Future goals include reaching full feature-parity with fzf, enhanced multi-column support (many possibilities here: editing, styles, output etc.), and performance improvements (a very far off goal would be for it to be able to handle something like the 1-billion-row challenge). There are a few points I have noticed where fzf is superior:

- fzf seems to be a little better at cold starts: this is due to a difference of between the custom fzf matching engine and nucleo -- the matching engine in Rust that matchmaker uses. I'm unlikely to change the _algorithm_ used in my nucleo fork, so if that matters to you, fzf is probably a better bet.

- fzf has some features like tracking the current item through query changes or displaying all results -- these will eventually be implemented but are low priority.

- Matchmaker supports similar system for event-triggered binds, and dynamic rebinding, but does not yet support fzf's --transform feature, which can trigger configuration changes based the output of shell scripts -- this is on the cards and will probably implemented in a different way. More importantly, I haven't tested this system too much myself, preferring to write more complicated logic using the library directly so I can't vouch for which approach is better.

Check it out here! https://github.com/Squirreljetpack/matchmaker