| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
On that page, we have regular expressions (which are not new-user
friendly) and an example (which is new-user friendly). So the example
should come before the regular expressions.
|
|
Conflicts:
background_scripts/completion.coffee
background_scripts/completion_engines.coffee
|
|
This commit contains the bulk og the material changes for which the
previous commits established the basis.
1) Add a general framework for detecting query prefixes in search URLs,
adding them to query sent to the completion engine, and stripping them
from the resulting suggestions. This allows the user to have a
search engine...
j: http://www.google.com/search?q=javascript+%s Javascript
and have the prefix "javascript" included (automatically) in queries
sent to completion engines, which results in substantially better
suggestions.
2) Re-work completion for Google Maps in a simpler form.
|
|
The original completion-engine interface was based on three functions.
With some experience, it seems there is a pattern involving explicit
regular expressions which is used by all actual engine implementations.
This is a refactoring to make those regular expressions explicit (and
required), and is a first step towards adding additional fucntionality.
This also simplifies the completion cache key (use JSON instead of some
weird hash).
|
|
|
|
Instead of just giving an example search URL, we can give the actual
declaration (which the user can copy, paste and tweak).
|
|
This allows the user to copy and paste search URLs from this page into
the options page.
|
|
With this, if we're in custom search mode and the cursor is at the start
of the vomnibar input and the user types <Delete>, then we exit custom
search mode and reinstate the keyword (and arrange for the cursor to be
in the right place).
This makes it possible to change (or just disable) the custom search
engine without having to first wholly delete the query.
|
|
|
|
|
|
|
|
|
|
See newly-added long comment for details.
|
|
This is a minor re-working of #1705 from @mrmr1993.
The main changes are:
- Simplify initialisation logic.
- Always initialise Settings immediately and automatically (ie. don't
initialise Settings separately and manually in the background,
content scripts, options and tests).
- Get rid of addEventListener (it's only being used for on "load").
- Add Settings.use() in its place.
|
|
|
|
|
|
|
|
(This was supposed to have been removed previously. Oops!).
|
|
|
|
Move "show-advanced-options" to a fixed-position button.
|
|
Move Vomnibar commands to own category on help page.
|
|
Direct keyboard access to custom-search engines via keyword flag
|
|
The help page gets pretty lopsided when advanced commands are shown. This balances things out a bit by creating a new category for Vomnibar commands in the right-hand column.
|
|
Ass suggested in by @LarryBattle in #1643.
|
|
This avoids a flicker whereby the keyword is first inserted into the
input, then removed.
|
|
Instead of directly accessing the background page's Settings object,
the options page and the page popup now have their own.
|
|
completion-on-custom-search-only-merge
Conflicts:
background_scripts/completion.coffee
|
|
In omni mode, the vomnibar suggestions are updated asynchronously.
Therefore, the contents of the primary custom search-engine suggestion
may be behind the actual contents of the comnibar input. So, we
reconstruct the custom search-engine query on "enter".
(This fixes a long-standing race condition.)
|
|
This option is no longer needed, since we don't do search completion
except for custom searches.
|
|
|
|
Do not use tab-to-open the vominibar in tabs mode. (It doesn't make any
sense.)
|
|
Underling is just ugly, in this case. Also, it is applied
inconsistently between titles and URLs.
|
|
Add header for Advanced Options.
|
|
Conflicts:
background_scripts/completion.coffee
|
|
|
|
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 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.
|
|
Omitting to remove these lines has the effect of disabling the
left/right keys in the vomnibar.
|
|
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.
|
|
With suggested completions appearing in the vomnibar, the meaning of
<Enter> can change when the completion list is updated, which happens
asynchronously. The user can end up selecting something they didn't
intend to ... which is bad.
This implements a temporary fix. When the completion list updates (and
the update might affect what the user expects <Enter> to do), we block
<Enter> for a short time (250ms). That's pretty bad too.
These UX issues around search completion are proving difficult to get
right. I will open an issue to discuss them soon.
|
|
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.
|
|
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.
|
