koreader-base VS fzy-lua-native

Can't give you a tutorial, but maybe it is interesting to you how we (well, I'm not an active part of the team anymore, it has evolved considerably after my active time in that project - back in the day, I kicked off the humble beginnings) in the KOReader project went on, so I suggest to study that. We've separated the "glue" part - https://github.com/koreader/koreader-base - from the "application" part, https://github.com/koreader/koreader That approach served well, if I'm any judge, since the former deals with C/Lua interop (API and LuaJIT's FFI), while the latter is a "pure" Lua framework. Start with reading "reader.lua", it will eventually call in the main application loop, UIManager:run().

I don't think it would be a good idea to integrate with telescope, I don't like the design of that plugin too much. Kirby's filtering backend uses fzy-lua-native, which is faster than out-of-the-box telescope. That backend was originally wrote for telescrope tbh (& vim-clap), but they never made it the default so AFAIK they still use lua filtering for basic cases.

It uses fzy-lua-native for filtering, another of my creations in need of love. It filters on the main thread but should be responsive for repos up to maybe a few thousand files.

fzy-lua-native similary doesn't use fzy, it's a matcher based on the algorithm that fzy uses. This is actually the same matcher used under the hood in telescope-fzy-native.

They really should make that extension the default. Besides, the backing fzy bindings also include a lua fallback, it would be much nicer for users to not have to mess around with tons of options to get a fast by default picker. (Disclaimer: I'm the author of the backing fzy bindings)

Anyway, if you're interested in doing the switch open an issue we can discuss further, but otherwise it's not a big deal.

I saw that you're spawning a new job for sorting things. If you're interested, fzy-lua-native is the standalone fzy lua bindings that telescope.nvim and other projects use. It comes with pre-compiled binaries for common OSes (included as-is, no install step needed; but just make otherwise), and fallbacks to a lua fzy implementation in case the binary fails to load.