Better search in history from address bar

Currently, autocomplete appears to perform a prefix match on URLs for autocomplete (excluding certain prefixes such as 'www'). For instance, if I have the website https://ppopp23.hotcrp.com open or in history, I can type ppopp2 (or any prefix of the url) into the searchbar to get:

However, if I type in hotcr (or in fact any substring of hotcrp.org), nothing shows up:

This contrasts with the behavior of matching for titles, which appears to be substring; e.g. "2023" (or any substring of) will match the title "PPoPP 2023" properly:

This is pretty annoying when trying to match websites that make heavy use of subdomains, such as Substack, most university websites, and reddit (since typing reddit will not match urls at old.reddit.com).

Suggestion: URL matching should be changed from existing prefix matching on the entire URL to one of these options:

• full substring matching, as is done for website titles, or
• prefix matching on every single parent subdomain for a website, i.e. in regex form, match (^|\.)query instead of ^query. For example, for the website abc.def.ghi.com, search queries should be prefix-matched against abc.def.ghi.com, def.ghi.com, and ghi.com.
• some combination of the above (e.g. prefix matching as a higher priority than title title matching, which in turn is higher-priority than full substring matching)

Now that Kagi is starting to count searches, I would like a slightly different search experience than before. For context, I currently usually start my morning by typing "nyt mini" in the address bar and pressing Enter (I'm sure there are some suggestions but I don't even look at them). The first search result from Kagi is "March 12, 2023 Daily Mini Crossword Puzzle" and while it's not March 12 any more, I click it and get today's NYT Mini Crossword. The other results are quite irrelevant for my task, so it is a shame to waste a Kagi token on the full search.

How I think this could work instead: when I press Enter and the search term is something I've used before, I first get an in-browser list of history results, with the most common history item on top. Somewhere on that page there would be a "Search on Kagi" button if I really wanted to rerun my search and not go to the same place as before.

I know there are bookmarks and whatnot, but I'm so conditioned to use text search that those are not on the top of my mind when I'm waiting for my morning coffee.

We would love if someone would summarize/consolidite this ask into one simple, focused ask

Here's an example string ranking algorithm: https://sourcegraph.com/github.com/quicksilver/Quicksilver@a239587a6e890056c83bf7c120967bfba63cc917/-/blob/Quicksilver/Code-QuickStepCore/QSense.m

Note that it's very sensitive to order, since it's usually used to search in filesystems, not in history entries:

You can try a derivate of it here: https://fwextensions.github.io/quick-score-demo/, and compare it to other popular string ranking libraries, or even the original Quicksilver algorithm.

Here's the json to try the examples @Gamma posted in Gamma:

[
{"title": "github.com/borgbase/vorta: Desktop backup client for Borg backup", "url": "github.com/borgbase/vorta"},
{"title": "github.com/httpie/httpie: whatever", "url": "github.com/httpie/httpie"},
{"title": "tabby.sh: A terminal for a more modern age", "url": "tabby.sh"},
{"title": "borgbackup.org: Deduplicating with compression and authenticated encryption", "url": "borgbackup.org"},
{"title": "github.com/grafana/k6: A modern load testing tool", "url": "github.com/grafana/k6"}
]

Note I have concatenated the title to the URL to be able to match across both, but it doesn't work for modern GitHub as the search term because of the aforementioned order sensitivity. There might be string ranking algorithms that are much more suited to this, or even ranking algorithms that can rank across multiple fields (you'll notice the example pages ranks url and title separately, then order by max score of either, that doesn't work for search strings that match partly in the url and partly in the title).

This approach to ranking generally scales quite well as you can compute score for all candidates in parallel, and you can easily build the results up incrementally since new candidates do not modify the score of existing candidates, so are you find new hits you can easily insert them in the partial results that you're already displaying.

Again note that the Quicksilver scoring algorithm specifically might not work well in practice for bookmarks / history, but I wanted to describe the concept of score ranking in general and it's is a very popular one.

Gamma Can you describe the Orion behavior in this case curently? We did change the alogrithm several times.

I can't speak for the specifics of @Gamma's use case, but the example they gave in the OP is still relevant, repro steps:

1. Open https://orionfeedback.org/d/2224-better-search-in-history-from-address-bar
2. Type "orionfeedback history" in address bar

Expected: pages including orionfeedback and history in the url or title or combination of the two are suggested, including https://orionfeedback.org/d/2224-better-search-in-history-from-address-bar.
Actual: nothing is suggested.

Gamma Thanks for confirming, closing this.