ii14 / fzx Goto Github PK

Even though there is no stable C/C++ API yet, the core library should work on Windows already.

EventFd class that uses unix pipes to wake up external event loops is currently missing on Windows. This is required to make it work as a Lua module with neovim and libuv. It could technically link to libuv and use uv_async_t, but I'd prefer the Lua module to remain agnostic to that and just expose a file descriptor, so I don't have to worry about ABI compatibility.

The standalone TUI is nowhere near done on Linux and Mac. No plans to support it on Windows right now. Just making it usable somehow inside neovim should be enough. Do people actually even use fuzzy finders on the Windows command line, outside of WSL or whatever?

The current TUI is really bad, and was meant to just test things out. Improve it.

When building as a shared library (lua module), the default visibility prevents function inlining and every call has to go through the PLT/GOT, which is slower than calling virtual functions. Build with -fvisibility=hidden and export only the symbols that are actually needed. Basically only the luaopen function and the C API (#10).

Right now available instruction sets are detected at compile time in cmake. Detect the available CPU features at runtime, so it's possible to ship binaries without dragging them down to the lowest common denominator.

Figure out the lowest required cmake version, so it's not too annoying to compile the project for people.

Add the option to run as a separate process and talk over msgpack RPC.

Option to build with Google's vqsort or Intel's x86-simd-sort.

x86-simd-sort is only AVX2 and AVX512. vqsort can do SSE too, but as far as I can tell it doesn't bring much of any actual improvement over libstdc++'s std::sort.

When strings are created, detect UTF-8 and store them as UCS-4. Storing them as code point values will make dealing with them easier, processing will be faster (conversions are done on the way in), at the cost of some memory usage (I'm assuming strings will be mostly ASCII anyway). This will require no significant changes to the code (SIMD or scalar) except switching to wider integer types when necessary.

Just like in fzf.

• 'foo for exact match
• !foo for negation
• ^foo for beginning
• foo$ for end.