Exact match in search should be prioritized.

[coke]

This occurs with many items, but the most obvious is searching for Inf

There is a unique match for Inf which should appear at the top of this list:

https://docs-dev.raku.org/type/Num#Inf

However, it's buried under dozens of infix operators.

The simple fix for this: an exact match should be at the top of the results list. The challenge - results are currently categorized.

Two ways to address that:

1. Have a prelim "category"/section (with or without a header) to show just exact matches if any are present (if shown here, they don't need to be shown again in their category)
2. Eliminate categories as headings and make them part of each result row.

I'm leaning towards 1.

[finanalyst]

@coke the ask seems reasonable - have searches that yield exact matches first. (I have wanted something like that too).

The problem is that we are dependent on an external library that filters through a fixed list of alternatives supplied with the page.

We have three stages in the search

1. Get the large set of candidates (this happens only once per page refresh)
2. The list is ordered into categories before filtering for desired candidates (this step should be fast because we pre-sort the candidates list at Build time). But the ordering is independent of the yet to be determined search criterion.
3. Filter for candidates (remove from candidates list those that do not match the criteria)

The ask - I think - implies one or two more stages,
4. Select from candidates those with 'exact' match

• Place 'exact' candidates at the head of the output list.

This would need some extra code around line 99 of Website/plugins/options-search/options-search.js

The challenge, I think, would be creating the JS regex for the 'exact' string.

I do not think your option 2 would affect the desired result.