Support prefix-only matching against haystack terms?

[jacobcarpenter]

Somewhat related to the discussion in #80 (and #58), I'm finding myself wanting haystack string prefix-only matching (with typo tolerance).

It seems like it might not be crazy to introduce a new interLft = 3 option above the current strict level for {whole string}-anchored matching.

That is, given a list like

const specialties = [
  // ...
  'Close Quarters Combat',
  // ...
  'Quartermaster',
];

I want quart to only match "Quartermaster".

I'm currently achieving this with something like:

const filterResult = uf.filter(haystack, needle);
if (!filterResult?.length) {
	return [];
}

// require matches to anchor to the beginning of the haystack term
// "quart" -> ❌ "Close Quarters Combat" ✅ "Quartermaster"
const info = uf.info(filterResult, haystack, needle);
return info.idx.filter((_, index) => info.start[index] === 0);

... but it sounds like info is doing a bit more than needed to just ensure the match is anchored to the haystack string start.

Interested in whether that seems like a reasonable request?

[leeoniya]

the order of the results should already by putting the best matches in the beginning, and even with typo tolerance, the default behavior still requires the first letter to match exactly, so you could technically just go down the order result list and trim off any matches that dont start with "q". not perfect, but probably good enough?

[jacobcarpenter]

Hm. It seems like a heavily alliterated haystack could easily defeat that approach, but maybe I'm not understanding the proposal.

"Another Awesome Alliteration"
"All Apples Are Amazing"
"An Apathetic Alligator"

needle: "all"

[leeoniya]

correct.

i'm pretty sure you can use the info struct to skip any matches that did not start at index 0, since that's already utilized as a sorting metric.

info.start:

uFuzzy/dist/uFuzzy.d.ts

Line 180 in 941711d

start: number[];

[jacobcarpenter]

i'm pretty sure you can use the info struct to skip any matches that did not start at index 0, ...

Totally; that's what I'm doing on the last line of my example code in the initial post. I was just concerned about the performance implications of the otherwise unnecessary info call, since it sounds from some of the docs like it does more work than filter.

In my use case I'm purely filtering a list and don't even want reordered results, so I'm retaining the order from filter, and dropping items that don't start at 0. It just seemed like the additional requirement of anchoring to the start could be achieved cheaply in the filter phase—and probably even make filter faster, if the regex is anchored to haystack term starts...

[leeoniya]

sorry, i totally missed that you were already doing this 🤦

i have some reservations about using interLft = 3 since that's meant to affect every term in the needle, but admit that it's a pretty clean way of implementing this in the filter pass. probably not terrible.