wincent ( Greg Hurrell )

Once you're in C-land you can created threads and then call pthread_join() which will block, waiting for the thread to terminate. So the Lua side doesn't even know about this little excursion off into the land of parallelism; it just blocks waiting for your FFI code to return. At least, that's the theory (based on how it worked with Vim calling into Ruby calling into C like it does on the master branch).

right I was not thinking on spawning threads directly in C-land for some reason.

Note that it is a synchronous search, so it has to be fast, otherwise Vim will seem to lock up...

Yes that was my experience with other sorters with telescope (actually it felt slow but non blocking because telescope tries hard not to fully block the ui)

it never got to he point of being too slow. It's nice to have options though, because these monorepos only keep growing.

I know, I work with a monorepo as well... not that big but still...

wincent

comment created time in 16 days

issue commentwincent/command-t

Port to Lua

which means it has to be very fast even on repos with > 1,000,000 files.

That's very good to hear, before trying to use command-t's matching algorithm I tried the telescope-fzf-native.nvim and with ~80k files it was struggling.

The goal is to port the entire thing (the match scoring and the parallel thread-based matching)

That is something that right now is very difficult with telescope being single thread and running in the luajit embedded in Neovim. I wanted to experiment with external process over msgpack-c (similar to what I'm doing with completion https://github.com/vheon/ycm.nvim) but again the telescope API is not meant to be used in this way.

Anyway thanks for the insight on the roadmap!

wincent

comment created time in 16 days

startedwincent/terminus

started time in 16 days