Skip to content
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

Open
fdncred opened this issue Sep 8, 2023 · 10 comments
Open

Starter example? #23

fdncred opened this issue Sep 8, 2023 · 10 comments

Comments

@fdncred
Copy link

fdncred commented Sep 8, 2023

A simple starter example would be a great addition.

@nrdxp
Copy link

nrdxp commented Apr 2, 2024

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:
nrdxp/skim@ec81510#diff-ee16942439f91e6bbf9180667c1c3d8cba41f66cb04e3236bef20cd35e5babc6

Although I'm sure there are edge cases still hiding

@pascalkuthe
Copy link
Member

pascalkuthe commented Apr 2, 2024

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)

@fdncred
Copy link
Author

fdncred commented Apr 2, 2024

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.

@nrdxp
Copy link

nrdxp commented Apr 2, 2024

@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.

@pascalkuthe
Copy link
Member

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 Matcher directly, use Nucleo instead

@nrdxp
Copy link

nrdxp commented Apr 2, 2024

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

@pascalkuthe
Copy link
Member

pascalkuthe commented Apr 3, 2024

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)

@kirawi
Copy link
Member

kirawi commented Apr 6, 2024

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)

@alexrutar
Copy link
Contributor

For those still looking for examples, I recently wrote a thin wrapper library around nucleo: https://github.com/autobib/nucleo-picker. I mostly just re-exposed the excellent API already exposed by nucleo, with most of the effort put into terminal rendering.

The inner picker loop and the find example might be useful!

@Denzo77
Copy link

Denzo77 commented Nov 20, 2024

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants