Add SearchMode fzf.

[pmarschik]

Add a new search mode "fzf" that tries to mimic the search syntax of
https://github.com/junegunn/fzf#search-syntax
This search mode splits the query into terms where each term is matched
individually. Terms can have operators like prefix, suffix, exact match
only and can be inverted. Additionally, smart-case matching is
performed: if a term contains a non-lowercase letter the match will be
case-sensitive.

I've also refactored the client database tests to be more readable.

Future improvements:

• add setting that allows switching the case mode between: smart (implemented), ignore (always case-insensitive) and exact.
• use https://github.com/lotabout/skim for parsing terms and generate query from there, this would allow braces to refine operator precedence.
• implement re-ordering of fzf searches where each term contributes to a score (could use skim for scoring as well)

[panekj]

You can use atuin history list --cmd-only | fzf

[ellie]

Thanks for this! 🥳

I'll give the code a proper look later, but will try running your branch for a bit today.

[pmarschik]

You can use atuin history list --cmd-only | fzf

I'm aware that this is possible. But implementing the search mode at query time allows us to use the other filters like --before, --after, --exit, --cwd directly. Also it should be faster constraining the matches on database level than querying everything and then fzfing.

[panekj]

IMO, it's a bad idea to implement such features instead of improving interop with external software, as it increases maintenance, binary size and there will be implementation differences.

Additionally having a better pipe support would benefit not only fzf users but similar and completely different programs as well.

[conradludgate]

I do also think that this extra complexity needs to be taken carefully. I have some (long overdue) clean ups of some of the sql code to remove the use of format! and this is going to add to that work too, since this makes even heavier use of that.

However, if this is a feature that's very desirable, then it does make sense to take on said complexity

[ellie]

I think I'm happy for us to take on the complexity here. I'd suggest that we actually replace the current fuzzy implementation with this though, rather than adding a new setting called fzf. In my usage so far, it's nicer than what we have at the moment :)

This way we're not tied to the implication we will match fzf, and can expand with more improvements in the future if needs be

I appreciate the concern there @panekj, but I'd rather focus on the use case of users using our TUI. Searching and then piping works fine, but it's not as good (and probably never can be as good) as searching with the correct term in the first place

[conradludgate]

Overall, code looks good. Just some nitpicks

[conradludgate]

LGTM

[ellie]

Thanks @pmarschik! Can't wait to get this released 😁 🚀