-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Starter example? #23
Comments
Not sure if this is inline with what you are wanting, but I forked skim to use nucleo just as an exercise. It was surprisingly easy and you can check out the code on my fork branch. I made some unrelated changes in that branch as well, but this was really all that was needed to use nucleo: Although I'm sure there are edge cases still hiding |
Please don't use the API like this. This will be much slower than an implementation using the high level api. The low level api is not meant for a real world interactivr fuzzy matcher. Only when you have something non-interactive or where you can't fit the low level api. The high level nucleo api provides a highly optimized parallel matcher. You can take a look at the helix picker for a real world use (altough there is ofcourse a lot of unrelated code there) |
@pascalkuthe Unraveling helix's picker with all the unrelated code isn't trivial. I started there months ago and quickly learned that it was too convoluted for me to easily figure out, which is what lead me to file this issue. @nrdxp Thanks! I'll take a look. |
@pascalkuthe thanks for the tips, it was just a quick and dirty first pass to see how much effort it would require without breaking too much. I plan to make a few more passes to hopefully optimize it as well, where I will allow myself to break the API a bit more now that I've cleaned up the code a bit (and I'll take your comments into account). Skim hasn't seem any activity for a while, so I figured it should be pretty safe to fork and play with, and if something useful drops out, then all the better. |
There is probably very little point on forkoog skim because almost everything skim does is handled by the high level nucleo api. You only need to write the rendering and input handling and hook that up with the high level nucleo api. As an applications you should never touch |
The main reason I wanted to use skim was for it's fzf compatibility, and also just as an exercise to get familiar with the nucleo api. After getting a bit more in touch with the code I can see that there is definitely a lot of crossover from the high-level nucleo api and skim itself so I can see your point. Not sure if it would be easier to write an fzf clone from scratch with nucleo or just rip out as much ad hoc code as possible from skim and replace with nucleo |
most certainly the latter, I essentially already did that with the picker in helix. It wasn't too hard. Skims high level code is also quite lacking in the performance department. I put more work into the high level nucleo code than the matcher itself since that is in practice more improtant than the actual matcher speed. Skims high level code is mostly a port of fzf from go to rust. Fzfs architecture is build around having a GC and doesn't perform well in rust. Nucleos architecture is fundamentally different and should perform at-least as well (likely faster but can't make that claim sicne I never got around to benchmarking properly) |
https://github.com/MangoTzara/rfz may be more approachable (IIRC pascal said there were some issues with it but it should serve as a decent starting point) |
For those still looking for examples, I recently wrote a thin wrapper library around The inner picker loop and the |
I was struggling to get a feel for the high level API so I ended up making a really basic example: https://gist.github.com/Denzo77/fecb55abd5eb2094585ba6517e90a5e8 Hopefully it saves someone some time... |
A simple starter example would be a great addition.
The text was updated successfully, but these errors were encountered: