aboutsummaryrefslogtreecommitdiffstats
path: root/background_scripts/completion_search.coffee
diff options
context:
space:
mode:
authorStephen Blott2015-05-13 20:02:50 +0100
committerStephen Blott2015-05-13 21:03:38 +0100
commitafb9bec09d3212c56fa3b82ed89ebb34e3a3f562 (patch)
tree58beac0528fa44768748e497af3a8936c2fddf98 /background_scripts/completion_search.coffee
parent176cac1249e1ee063ef0cadf05d7b090650686fb (diff)
downloadvimium-afb9bec09d3212c56fa3b82ed89ebb34e3a3f562.tar.bz2
Search completion; complete rework of UX.
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.
Diffstat (limited to 'background_scripts/completion_search.coffee')
-rw-r--r--background_scripts/completion_search.coffee14
1 files changed, 10 insertions, 4 deletions
diff --git a/background_scripts/completion_search.coffee b/background_scripts/completion_search.coffee
index a9521a3d..c6824594 100644
--- a/background_scripts/completion_search.coffee
+++ b/background_scripts/completion_search.coffee
@@ -1,6 +1,6 @@
CompletionSearch =
- debug: false
+ debug: true
inTransit: {}
completionCache: new SimpleCache 2 * 60 * 60 * 1000, 5000 # Two hours, 5000 entries.
engineCache:new SimpleCache 1000 * 60 * 60 * 1000 # 1000 hours.
@@ -75,13 +75,16 @@ CompletionSearch =
# Verify that the previous query is a prefix of the current query.
return false unless 0 == query.indexOf @mostRecentQuery.toLowerCase()
# Verify that every previous suggestion contains the text of the new query.
- for suggestion in (@mostRecentSuggestions.map (s) -> s.toLowerCase())
+ # Note: @mostRecentSuggestions may also be empty, in which case we drop though. The effect is that
+ # previous queries with no suggestions suppress subsequent no-hope HTTP requests as the user continues
+ # to type.
+ for suggestion in @mostRecentSuggestions
return false unless 0 <= suggestion.indexOf query
# Ok. Re-use the suggestion.
true
if reusePreviousSuggestions
- console.log "reuse previous query:", @mostRecentQuery if @debug
+ console.log "reuse previous query:", @mostRecentQuery, @mostRecentSuggestions.length if @debug
return callback @completionCache.set completionCacheKey, @mostRecentSuggestions
# That's all of the caches we can try. Bail if the caller is only requesting synchronous results. We
@@ -104,8 +107,11 @@ CompletionSearch =
# incorrect or out-of-date completion engines.
try
suggestions = engine.parse xhr
+ # Make all suggestions lower case. It looks odd when suggestions from one completion engine are
+ # upper case, and those from another are lower case.
+ suggestions = (suggestion.toLowerCase() for suggestion in suggestions)
# Filter out the query itself. It's not adding anything.
- suggestions = (suggestion for suggestion in suggestions when suggestion.toLowerCase() != query)
+ suggestions = (suggestion for suggestion in suggestions when suggestion != query)
console.log "GET", url if @debug
catch
suggestions = []