| Age | Commit message (Collapse) | Author |
|
For each completion engine, this adds an @example properties (not
comments)
|
|
When the user changes custom search engine during a single vomnibar
activation, we should only offer suggestions which match the current
search engine (not the previous one).
We now do this not just by checking that the suggestion is a custom
search suggestion, but by checking that the actual search URL matches.
|
|
In Google Maps, we get a new history entry for every pan and every zoom.
This removes such duplicates.
|
|
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.
|
|
|
|
|
|
Conflicts:
misc/completion_engines/completion_engines.md
|
|
We need to use "\\." to get a literal ".".
|
|
Allowing mapping <space>.
|
|
Move Vomnibar commands to own category on help page.
|
|
Direct keyboard access to custom-search engines via keyword flag
|
|
|
|
|
|
This removes a couple of lines which should have been removed
previously.
|
|
|
|
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.
|
|
"Flags" implies binary toggles. The term "options" seems more
consistent with what's actually going on here.
|
|
This will allow us to use the same search-engine parsing code in the
background page and in content scripts.
|
|
|
|
|
|
This completely decouples settings.coffee from all other background
source files, so that it can (eventually) also be used in the frontend.
|
|
This stops Sync from being referred to from anywhere except
settings.coffee and settings_test.coffee.
|
|
This function does nothing related to Sync, and only affects Settings.
|
|
|
|
|
|
Most of this is just a tidy up of code that's been around for a long
time.
The only difference, however, is that now a key mapping can include
extra data ("extras") after the name of the command. For example,
map s vomnibar.activate keyword=g
Here, and extra property "extras" is added to the command registry:
extras: ["keyword=g"]
This is a first step towards direct vomnibar activation for custom
search.
|
|
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 optimisation is now unnecessary, because we will *always* show at
least one completion suggestion in top spot.
|
|
This ensures that <Tab> can always be used to complete the top-ranking
completion.
|
|
This option is no longer needed, since we don't do search completion
except for custom searches.
|
|
|
|
|
|
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.
|
|
Two errors fixed...
|
|
|
|
|
|
This makes nextTab and previousTab go directly to the relevant tab,
without visiting intervening tabs -- all of which avoids a nasty flicker
for 5J or 5K.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Fixes #544.
Copy of #655.
|
|
|
|
|
|
Conflicts:
background_scripts/completion.coffee
|