Starter example?

[fdncred]

A simple starter example would be a great addition.

[nrdxp]

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]

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]

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]

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

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]

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]

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]

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)