Maintenance / Preferred Fork?

[MrAwesome]

First off, I'm a huge fan of the project. It does exactly what I need it to do, and much better than other libraries I've tried. It's strictly better than many larger and more active JS search projects in simplicity, speed, and intuitiveness.

I just want to clarify what users of the library should do to get access to updated code - there haven't been any code updates in ~4 years, despite multiple open+unaddressed pull requests in that time span (#91, #84, #74, #72, etc). It seems like there's sufficient community interest in keeping this thing going and growing it, but without the ability to merge code we're kinda at a loss.

So this brings up two paths forward, only one of which we need to bother going down:

1. Is it possible to add new maintainers to the project? If so, who is interested and what should that process look like?
2. If that's not an option, is there a preferred fork the community can/should use instead? And if there isn't, is there interest in creating one? And if we take this path, is it possible to link directly to the preferred fork from this repo?
   ( Currently there are 144 forks, and no indication as far as I can see that any of them are intended/ready to take on the maintenance burden: https://techgaun.github.io/active-forks/index.html#farzher/fuzzysort )

Between the two, I personally would prefer the first. Losing the domain expertise and vision, along with introducing a split-brain scenario, seems like a worse outcome to me.

And just to be extra clear, @farzher @kyuwoo-choi - I'm really thankful for all the work you've put in on this. Just want to find a solution where those of us using the project are able to contribute and build on what's here.

[farzher]

First off, I'm a huge fan of the project. It does exactly what I need it to do

exactly. most of the pull requests are unnecessary and just make things more complicated and slower.

#91 makes everything slower. #74 isn't an issue? #72 / #84 aren't important.

those unimportant ones should probably be pulled, but the benefits are soo tiny that i didn't think the potential of pushing a bug and a new version after 5 years was worth it. example: #81 (comment)

i'm happy to link directly to a community fork, and pull specific changes if you can convince me.

[MrAwesome]

Sorry, that's me being a little too polite for my own good. Fuzzysort as it is today does fit my basic needs for my project, but there are definitely features that I want, especially (optional?) Unicode support (very relevant to my project) and callback support (#66). The others are linked less because they're important (I don't know how to judge that) and more because they weren't responded to or closed (#74 was a wrong number, dunno which one I was thinking of).

I think the main sticking point then is that a lot of these issues and pull requests haven't had any replies for months or years, so people are just sorta left wondering if anything is going to happen. I think a more clear "no" + wontfix/close to those of us wanting to add new features would be a nice touch going forward, at the very least.

[farzher]

there are definitely features that I want, especially (optional?) Unicode support (very relevant to my project)

what kind of unicode support do you want? this? #23 (comment)
the pull request #91 doesn't do that

and callback support (#66).

ok you've convinced me

I think a more clear "no" + wontfix/close to those of us wanting to add new features would be a nice touch going forward

i feel bad saying no though D:

[MrAwesome]

ok you've convinced me

Nice :D

what kind of unicode support do you want?

I'm maybe confused on this. It seems from looking at the code that beginning indices are only computed for ASCII, right? I'm a little fuzzy (...eyyy) on what exactly that means in the algorithm, but it looks like it's setting start points for improved scoring of words?

I'm doing a lot of searching in Chinese characters and accented characters (and eventually languages across the utf8 spectrum). I do have a normalized field for the accented characters, but there are plenty of situations where people will want to search for non-normalized matches in the target languages (particularly in non-Romantic languages, where normalization doesn't do anything).

What about either of these options?

1. Allow users to pass in override functions for isUpper and isAlphanum, and if they're present use them instead of the current versions?
2. Have a flag for unicode or unicodeBegginingIndices, or a list of field names which should use the Unicode calculation (or custom isUpper/isAlphanum)instead?

i feel bad saying no though D:

Lord. I feel you. At least on a PR, a no feels like a great gift, because it means you can close that mental loop and move on :}

I'll go ahead and close this, since you're clearly still active! Happy to keep discussing the Unicode thing here or elsewhere.