Use autoComplete.js library, simplify search

[CIAvash]

I don't know if people want this, but I've been spending some time on the docs search to use vanilla JS library and code and to simplify both the search and its JS code.

Library used: autoComplete.js

Probably fixes #79 as well

[CIAvash]

I forgot about the search button, what does it do currently?

[2colours]

The search bar didn't seem to do anything more useful previously, either. it can close the search bar but it cannot even open it and it doesn't search whatsoever.

For the change - in my opinion:

Pros:

• the code is much more readable
• no jQuery "triQuery" :D
• it does fix the weird mouse+enter combos

Con:

• I miss the categories. Could be that I'm just not used to this design but right now, I feel the overall look would be better with the categories preserved.

Overall, I think that search code was so messy and unreliable that this work cannot be neglected - neither practically, nor "pedagogically" or how to put it, I mean it's respectable that someone went ahead and made this necessary change. However, I would like to see how this could work with categories, because I think it would be good to preserve that as well, and that was definitely a significant part of the complexity in the old code.

[CIAvash]

I miss the categories. Could be that I'm just not used to this design but right now, I feel the overall look would be better with the categories preserved.

The categories are still there, but shown on the right hand side, does the previous design do something special with categories? Or maybe you mean the categorization? If yes, it should still be possible, but the reason I like this approach better is that the relevant results get to the top without categories or the order of categories getting in the way(which is more intuitive to me). The categorization may bring less relevant results into user's attention, and if the order of the categories are kept, it'd look confusing to me.

[2colours]

Yes, I meant that we are jumping around between categories... especially when one wants to look up some special character - a parameter type, a sigil, an operator, a regex symbol - or something that happens to match e.g. certain exception names, I think it's a reasonable assumption that you can make a choice between the categories, and the otherwise accurate matches could be ignored, simply because they aren't the category you care about.
If there wasn't any other reason to keep the grouping, I think the entries that have the same name in different categories and stack up visually - by the way, some entries are plain redundant so perhaps there is an additional docs issue in effect - avoiding this visual situation is a good enough argument in my eyes.

I'm not sure how much the left side bar (which is also a kind of search from what I know) can assist this. Maybe it's just one needs to get used to a different workflow for browsing the site from what I've been using.

[CIAvash]

One other thing that can be done is the narrowing we do with some symbols, for example if the search starts with &, subroutines and methods are shown, similarly we can do the same for categories(although it may be more cumbersome), for example query starting with regex searches the regex category or something like that.

And then there is the extended search which allows searching based on categories, maybe if someone is looking for something specific, should use that instead?

[Altai-man]

One other thing that can be done is the narrowing we do with some symbols, for example if the search starts with &

The old code does that, is it preserved in the PR? Sorry, burning out on $dayjob to look into it for real now. :/

[CIAvash]

One other thing that can be done is the narrowing we do with some symbols, for example if the search starts with &

The old code does that, is it preserved in the PR? Sorry, burning out on $dayjob to look into it for real now. :/

Yes.

[Altai-man]

I looked at how it works, I like it very much! Feels like it started to work faster too.

The only problem is that it doesn't really support Levenshtein distance matches? In the old implementation I could write trm and it'll return trim, but now it requires an exact substring. Would that be difficult to implement?

But otherwise - awesome!

[CIAvash]

That is because of the search mode, it fits my brain and some of the tools I use, by default it does exact match and if the query contains an space it does loose/fuzzy match, so for example if you write io path it matches what you want, but iopath doesn't work; if you put an space in front or at the end, or well anywhere, it does what you want, so in case of trim, if you enter " trm" or "trm ", it does loose match.

docs.raku.org/templates/search_template.js

Line 52 in d4cbe47

const mode = query.includes(' ') ? 'loose' : 'strict';

If that is not desired, I can change it to make the loose search, the default and do exact search maybe by a prefix command. Or just use loose match and not do exact match.

[Altai-man]

That is because of the search mode, it fits my brain and some of the tools I use

Aha, I see.

Let's do it fuzzy by default (it still prefers explicit matches as I understand it), and can be merged and shipped. Awesome work!