| Age | Commit message (Collapse) | Author |
|---|
|
Float find-mode matches to the right.
|
|
This floats the "5 Matches" text in the find-mode HUD to the right.
This looks nicer, because the "5 Matches" text doesn't move as you type.
As it happens, it also fixes an issue which arose a few months ago (for
unknown reasons) with the positioning of the cursor in find mode. The
cursor position was becoming "jammed" after the first character as you
type.
|
|
|
|
|
|
|
|
This means that we get the new tabs in the same order as they are
specified in the key mapping.
|
|
Example:
map a createTab http://edition.cnn.com/ http://www.bbc.co.uk/news
which creates two new tabs, but preloaded with these specific URLs.
`2a` creates four new tabs, two copies of each.
Limitation:
- We cannot control the order of the tabs, so we might get CNN then BBC,
or BBC then CNN. This happens because command options are stored in
an object, and we cannot control the order of the keys.
Also, with:
map a createTab http://www.bbc.co.uk/news http://www.bbc.co.uk/news
we only get one new tab (same reason as above).
|
|
Keep the option list (in addition to the parsed command options) because
some commands may depend upon the command option order. One currect
example is #2318.
|
|
Rework key-mapping parsing and help-dialog HTML
|
|
(Because we're scanning backwards throught the mappings, we shouldn't
overwrite an existing mapping.)
|
|
|
|
Previously, the dynamic HTML for the help dialog was generated on the
background page. The HTML itself was tangled in with program logic.
Here, we move all of the HTML to HTML5 templates; also, we build the
help-dialog contents in the help dialog itself, not on the background
page.
Note: #2368 is included here too.
(Background: I'm trying to clean up some of the command and help-dialog
logic in preparation for addressing the issue of how to document command
options, see #2319.)
|
|
There are two changes here:
1. Treat built-in key mappings and custom key mappings in the same way;
that is, we prepend the built-in mappings to the custom mappings and
then parse them all together. This results in a number of
simplifications due to previous duplication of logic and the elimination
of special cases.
2. Parse key mappings in reverse order, so we can just ignore key
mappings after first encountering a key sequence. So, `map`, `unmap`
and `unmapAll` are all treated in more or less the same way.
This is preparatory to reworking some aspects of the help page. In
particular, regardless of the order of maps, unmaps, etc., this approach
makes it easier to find the mapping in effect for a key sequence (and be
able to recreate the order of those mappings).
|
|
Move SearchEngines to bg-utils.coffee.
|
|
|
|
|
|
|
|
|
|
case when link hints are generated
|
|
`SearchEngines` was previously in `utils.coffee`, which means it was
loaded in *every* content frame. This is unnecessary, since it is only
used on the background page. So this PR moves it there.
Also:
- Simplify some unnecessarily complex logic in `vomnibar.coffee`.
- Re-use `Utils.parseLines()` to parse the custom search engine configuation text.
|
|
|
|
|
|
Better line parsing (for custom key mappings)
|
|
|
|
|
|
1. Explicitly remove comments.
2. A trailing backslash means the current line continues on the next line.
E.g.
a \
b \
c
is a single line `a b c`.
This helps alleviate the fact that configuration lines can be very long,
whereas the *Custom key mappings* input is quite narrow.
TODO: We should use the same line parser in the custom-search-engines
input.
|
|
|
|
|
|
Here's the problem...
Many sites define their own keyboard shortcuts, for example Google Play
Music defines `gh` for "go home".
On such sites, it's natural to set up pass keys for `g` and `h`.
But that makes any Vimium key bindings which begin with `g`
inaccessible.
Here, we add a new command `enterNormalMode` which installs a new
normal-mode instance (without any pass keys). This executes a single
normal-mode command then exits.
Example:
map \ enterNormalMode
map | enterNormalMode count=999999
Assuming `g` and `o` are pass keys:
- `gh` or `o` - use the page's binding
- `\gg` - scroll to top
- `2\ggo` - scroll to the top and open the Vomnibar
- `\g<Escape>o` - open the Vomnibar
- `\<Escape>o` - use the page's bindings
- `\\\\\\<Escape>o` - use the page's bindings (new normal-mode instances
displace previous ones)
This required some changes to the scroller. Previously, we only ever
had one normal-mode instance, and could arrange statically that the
scroller's key listeners were above normal-mode's key listeners in the
handler stack. Here, we fix this by adding and removing the scroller's
listeners dynamically, so they're always at the top of the handler
stack.
|
|
This is a no-op. It arranges that the registry entry for each command
is passed to the command, for every command.
That required a small ammount of reworking in a couple of cases.
|
|
Setting the update_url by default can lead to accidentally updating to
the version you host on github. Setting this to a safe default of "" and
leaving a comment explaining why.
|
|
Add "mapkey" command for key mappings.
|
|
|
|
|
|
smblott-github/disable-grab-back-focus-in-all-frames
Disable grab-back-focus in all frames.
|
|
When the user begins interacting with one frame, we disable the
grab-back-focus mode in *all* frames.
Previously, grab-back-focus was preventing users from selecting inputs
in frames other than the active frame.
Fixes #2296 (possibly).
|
|
|
|
Here, these map to escape:
translate x <c-[>
translate <c-c> <c-[>
|
|
Under *Custom key mappings* (on the options page), this implements:
translate x y
Whenever the users types `x` in normal mode or in visual mode, the `x`
is replaced by `y`.
For example:
map ç l
(which apparently would be helpful on Brazilian keyboards).
Issues:
- Do we want yet another hack like this? This would be documented only on
the wiki.
- If we allowed `translate <c-c> <c-[>` (and extended `isEscape()` to
use the translation), then we'd get the `exitMode` command for free
(#2253).
- Alternatively, instead of adding a new "command" called `translate`,
we could overload the existing `map` command. Since these are
single-key mappings, there's no ambiguity. (Although, I guess there's
a risk some user has junk in their key mappings and would be taken by
surprise).
Inspired by isssue posted by @vhoyer (#2305).
Fixes #2305.
|
|
Comminication by the frame's port is faster, and no response is sent.
|
|
We do not need the registryEntry's decription in the content scripts, so
remove it (saving a marginal amount of memory and time).
|
|
Partially addresses #2303.
|
|
When an <a> spans the end of a line and the start of the next line, we
now highlight both parts of the link (instead of just the first).
Also, refactor code for calculating the position of the viewport into a
separate utility in DomUtils.
|
|
handle documentElement's top/left margin correctly
|
|
Fixes #2299.
Also, separate this regexp out into its constituent parts, because it is
becoming too different to read.
|
|
|
|
|
|
|
|
|
|
|
