maybe we should also cache these buffers, right?

maybe just wipe them as soon as one closes the window?

Thank you for the review! I moved them to the FuzzyFindPopup alongside the matcher. Maybe I should move matcher and matcher_* to a new struct to omit this prefix?

is this branch up to date with master? I don't see the removal of fuzzy-matcher in asyncgit which got introduced in #1791

Sorry, this branch was really outdated, I merged latest changes from master

After a little digging in the asyncgit/src/sync/logwalker.rs, I realised that it would require more changes than in fuzzy_find_popup.rs

The main problem I'm struggling with is the fuzzy_match borrows Matcher as mutable, this will require some changes in the current implementation

The shortest way I see is this: we can wrap matcher in LogFilterSearch into RwLock, this will allow us to borrow filter as mutable only during the actual matching. Otherwise we'll be required to handle the entire filter and closures that borrow it as mutable everywhere (maybe I'm wrong)

Could you please advise how best to implement this?

Btw, the naive implementation with RwLock already shows that nucleo is faster alternative than fuzzy-matcher! I tested commit log filtering for the kubernetes repository (~117k commits):

For random query the debug build with nucleo takes ~5.5 sec, and the version with fuzzy-matcher takes ~6.5 sec!

Mutex is fine here since we won't have multiple readers and any benefit of RwLock for this.

I am not really aware of how your codebase works but I might mention here that fuzzy-matcher uses an implicit internal thread-local storage together with interior mutability to hide the same mutability that Nucleo has (and has similarly expensive allocations although they are lazy instead of eagerly). So if you are doing the matching in parallel (which I would recommend) the mutex will hinder nucleo and you would get better results by using one matcher instance per thread (the allocation is large but not that large either).

If you are looking to add an fzf like filter I would really recommend that you consider the high-level nucleo API (the nucleo crate). It performs the matching in parallel and can perform millions of matches with barely perceptible delay (on a beefy CPU). It's what we use in helix for the file picker (you can try it out by building this branch helix-editor/helix#7814 and running it in your root directory).

It also supports fully lock-free (and wait-free) parallel streaming so if you are iterating revs in one (or multiple) background threads that would work well too