| Age | Commit message (Collapse) | Author |
|---|
|
This ensures that URLs which differ only in their case are considered
duplicates, hence one is dropped.
|
|
|
|
|
|
|
|
|
|
|
|
When the user begins editing the inserted text from a
custom-search-engine suggestion, we reactivate the original
custom-search-engine mode.
|
|
Note: There's still an unpleasant flicker when this happens.
TBD: Fix this.
|
|
|
|
|
|
`o` then `Tab` opens the vomnibar completionlist with history
completions (the only completions) ranked by recently only. Hence, the
most recent requests are at the top.
This is a (far) simpler approach than #1662 which catches the most
important use case (repeat a search with an edited query).
|
|
If the URL contains a query term such as vierwaldstättersee, then we
render the URL encoded version in the vomnibar. It looks considerably
nicer to render URL-decoded version.
|
|
smblott-github/search-completion-with-regular-relevancy
Search completion with regular relevancy calculation
|
|
|
|
If we go with this and #1662, then we can share the utility.
|
|
|
|
See the comment in the diff.
This test was in a previous version, but was dropped because with
eb0e2964fca5ef2eccc06607944df6b208b2b99f, it was (thought to be) no
longer possible to filter by relevancy score since we don't know what
the relevancy score will be.
The filter is reinstated here because we use the simple idea that,
whatever relevancy scores are assigned to completion suggestions, they
will be less than the score for a perfect suggestion.
|
|
This is an alternative relevancy-scoring scheme for search completion.
It attempts to address the "clumping" effect described in #1651 by:
- Using the regular relevancy scoring scheme (but based only on the
title (so, not the URL).
- Weighting relevancy scores (exponentially) by the length the query
(so, search suggestions score higher as the length of the query gets
longer).
- Weighting suggestions (fairly moderately) by their position in the
suggestion list as returned by the completion engine. We generally
want to retain this ordering.
- Applying a calibration fudge factor to roughly calibrate (boost)
search-completion suggestions with those from other search engines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If we insert the text of hostory completions into the vomnibar input,
then when the completions change, we'll pick up the arbitrary text of
whatever happens to be the current selection. So we need to always
reset the selection when the vomnibar updates. This eliminates the need
for the previous autoSelect logic.
|
|
|
|
|
|
Two things:
1. Do not fire off requests to completion engines if the relevancy
score they are assigned wouldn't be enough to be included.
2. Fix off-by-one error in prepareSuggestions.
|
|
|
|
|
|
|
|
|
|
This is a major reworking of how the search-completion systems works.
Previously, the goal had been to emulate roughly how chrome itself
handles completions. This has turned out to be a bad idea:
- It creates issues around what it means to hit <Enter> in the
vomnibar.
- And the contents of the vomnibar change asynchronously (because we
fetch completions asynchronously), so it creates the possibility
that the effect of <Enter> changes depending on how long the user
waits before typing <Enter>.
All of that is bad.
This commit changes things:
- In normal omni mode, the vomnibar looks and behaves pretty much
like it always has, just with some extra completion suggestions
thrown in.
- And in custom-search-engine mode it also behaves mostly as it has
previously, but (again, possibly) with some extra completion
suggestions thrown in, and with many useless suggestions excluded.
This is all far more Vimium-like than Chrome-like.
|
|
|
|
|
|
I'm having difficulty getting all aspects of the UX right for all
combinations of modes. This is the latest attempt. The main goal is to
mimic Chrome to the greatest extent possible. There will be more to
come, but I think this is an improvement.
|
|
If the input is "w ", the user is going for something like "w query
terms" (a custom search engine).
So the domain completer should not offer completions if the user has
finished the first word.
|
|
This makes the behaviour consistent between custom and non-custom
searches when there is no selection in the vomnibar (omni-mode only).
Approach:
- When there is no selection in the vomnibar, we *always* send the
query to to background completer (that is, both for default
searches and for custom searches) and ask the completer to provide
only the primary suggestion. The primary suggestion is just what
you get if you append the query terms to the search URL (default or
custom). We then immediately open the first response.
The round trip for default searches isn't strictly necessary. However,
this uniform approach disentangles some nasty logic in the vomnibar when
we're trying to handle several cases (default or custom search, with or
without prompted text, with or without any suggestions at all). The
extra round trip simplifies the logic to such a great extend that it's
worth it.
|
|
- We arrange that:
- for custom search engines, or
- for other searches where there is at least one match
that match is at the top of the list (relevancy 1).
This top suggestion will the suggestion which will be used to popuplated
the promted text in the vomnibar. If we arrange that it's at the top of
the list, then it is also the text that we get in the vomnibar if we hit
<Tab>.
This leaves us in the position where:
- If the user wants just the text they've typed, then they hit
<Enter>.
- If they want all of the text in the input (including the prompted
text), then they hit <Tab>, <Enter>. This is a very natural UX.
It feels like <Tab> is filling in the prompted text, although all
it's really doing is choosing a suggestion (the first one), as it
always has done.
There is one small catch. We need to avoid a clash with the domain
completer, which also likes to force its suggestion to the top of the
list. There's a test for that case. Basically, we can apply this trick
if it's a custom search, or if the user has finished typing the first
query term.
|
|
|
|
This applies only to custom searches for which we have a completion engine.
Status quo: Exclusively offer suggestions generated by this completer.
This PR: Also include other suggestions (e.g. history) if their URL and
query match this custom search engine.
|
|
- Remove various bits of URL fluff (the scheme, trailing URL separators).
- Remove various unhelpful Google search parameters.
- Filter for duplicates (based on the simplified URL).
|
|
Bugs:
- The serch-engine completer wasn't being configured correctly for the
case when we don't have a completion engine.
- Handle Control-Shift-Left/Right in vomnibar.
Also: better comments.
|
|
|
|
|
|
|
|
Conflicts:
background_scripts/completion.coffee
|
|
|
|
|
|
|
