| Age | Commit message (Collapse) | Author |
|---|
|
Also suppress highlighting of matching text in previous suggestions.
(It looks odd to have highlighting in some suggestions but not others,
with no apparent difference to the user.)
|
|
Fix incorrect property name from 764d70312f292882abe4940adf9fee3d6e834327.
|
|
|
|
Use a rightwards hooked arrow instead of a small greater-than sign,
which according to @philc, renders as a large greater-than sign on Macs,
See #1651.
|
|
|
|
|
|
|
|
Conflicts:
background_scripts/completion.coffee
|
|
|
|
|
|
See example in diff.
Do not offer a suggestion if it is what the user would get anyway if
they just hit <Enter>.
|
|
This reverts commit 4309dcd3030687f3ed02b86bbdf7c485baaee4a5.
This is a bad idea. It pushes the suggestion at the top of the list out
of the way. Users aren't going to like that if it's the one they're
looking for.
Conflicts:
background_scripts/completion.coffee
|
|
|
|
|
|
This address "UX Issue 2" from #1651.
If the user types "w lake vict" and sees a suggestion "lake victoria
perch", and continues "w lake vict pe", then we retain the previous
suggestion (which still matches) despite the fact that the completion no
longer delivers it.
This creates a more consistent, Vimium-like vomnibar UX.
|
|
|
|
Conflicts:
background_scripts/completion.coffee
|
|
|
|
This puts the first (top) completion suggestion at the top of the list:
either one or two <Tab>s away, depending upon whether a domain-completer
suggestion is present or not.
|
|
The relevancy score of completion suggestions should not change as the
user continues to type. See "UX Issue 1" in #1651.
(The effect of the previous implementation was that search completions
would jump, unpredictably, up the suggestion list, often displacing
suggestions from other completers for no reason which was apparent to
the user.)
|
|
Oops. I left this on, again.
|
|
|
|
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.
|
