| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The default (for when no options are provided) is of the wrong type.
This works as is, but should really be fixed -- as here.
|
|
Pass to count to scroll commands.
|
|
Currently, `10j` keeping `j` held down scrolls quickly for a time then
reduces back the regular hold-`j` scroll speed. Therefore, the user
cannot use a count to influence the smooth-scrolling scroll speed.
This PR fixes that by passing the count to the scroll functions.
Consequently, we adjust the actual scroll amount (which affects the
scroll speed) rather than calling the scroll commands several times
(which doesn't).
|
|
This implements a poor-man's build info.
See #1352. Unfortunately, that requires a separate build target, and
does not work with `cake autobuild`.
This just records the *install date* and displays that info on the
logging page. "Install date" because we can reliably determine it, and
because it does answer the question *have I upgrade Vimium on this
machine since last week?*. And on the logging page because that's out
of the way, and not part of the regular Vimium interface.
|
|
We need to multiply by `count=N` *before* checking `repeatLimit`.
Tweaks #2001.
|
|
With #2006 and #2009, this is no longer being used.
|
|
Remove (unused) `tabInfoMap`.
|
|
Conflicts:
background_scripts/commands.coffee
|
|
Fix `<count>removeTab`.
|
|
Previously:
map J scrollDown count=NotANumber
would break the command completely.
Fixes an error introduced in #2001.
|
|
Specifically, avoid reliance on `chrome.tabs.onSelectionChanged`.
If we merge this and #2006, then we can delete all of the
`chrome.tabs.onSelectionChanged` code.
|
|
|
|
|
|
We were incorrectly setting `options.count` to `NaN` if there was no
command option.
|
|
This fix the problem that `chrome.tabs.onActivated` won't be triggered
when we switch Chrome windows.
|
|
There's a nasty little bug in `removeTab` when you remove more tabs than
there are in the window (and there is a second window):
- all of the tabs in the currently-focused window are removed
- then, later (so, time passes), when you change tab in the other
window, we begin removing tabs again!
The source of the bug is our reliance on
`chrome.tabs.onSelectionChanged`, which doesn't first when removing the
last tab in a window (and there is another window).
Regardless, the previous semantics of `<count>removeTab` was
questionable. It was preactically impossible to predict which tabs
would removed. This picks the current tab, then those to the right of
the current tab, then those to the left.
|
|
|
|
It appears `tabInfoMap` (and related machinery) is not being used. This
removes it.
|
|
Make `moveToNewWindow` accept a count.
|
|
Add count command option
|
|
|
|
This make `moveToNewWindow` accept a count. For example, `3W` to move
three tabs to (the same) new window.
The tabs chosen are the current tab, then those to the right of the
current tab, and then those to the left of the current tab.
`999W` moves *all* tabs to a new window. It's not clear why you would
want to do that. An alternative would be to leave the last tab behind.
|
|
This strips out the legacy pre-chrome.sessions code. The API has been
in Chrome since version 37, and we probably don't really need to support
older versions than that.
|
|
Examples:
map j scrollDown count=10
map q removeTab count=999
|
|
When we introduced command options (for mapping keys to custom-search
engines), the parsing was done in the Vomnibar code.
This moves the parsing to `commands.coffee`, which is where it should
always have been.
This is a preliminary step with a view to adding a new `count` command
option.
|
|
Consider:
map q passNextKey
This works fine in normal mode. However, in insert mode, when the user
types "q" they expect "q" to be input. Any other behaviour would be
pretty weird.
Here, we filter out such mappings before the front end sees them. So,
with:
map q passNextKey
map <c-]> passNextKey
both mappings work in normal mode, but only the second works in insert
mode. This is probably the behaviour likely to cause least user
confusion.
|
|
This allows:
map a passNextKey
map b passNextKey
(Previously, we only picked up the first mapping.)
|
|
We need the key mapped to passNextKey in the front end so that we can
activate pass-next-key from within insert mode too (without the need to
consult the background page).
|
|
This implements a passNextKey command (initially for normal mode only),
as discussed in #1955.
|
|
|
|
These migrations are at least ten months old (since release).
|
|
- handle case where there's only one tab
- also focus the selected tab's window
|
|
Implements visitPreviousTab (as discussed in #1955).
|
|
Certain background-page utilities are actually shared, and are therefore
best placed in place that reflects that.
Here, tabRecency is moved to the new gb_utils.coffee in preparation for
implementing a go-to-previous-tab command. In particular, it is no
longer appropriate that tabRecency be embedded within the completion
code.
logMessage() from main.coffee is also a candidate for moving to
bg_utils.coffee.
|
|
|
|
|
|
|
|
Pass a count to link-hint commands, and the link-hint mode is started that many times (except "with queue").
This resolves the same issue as #1291. However, this:
- does not require re-basing (which is no biggie), and
- keeps all of the count-handling logic (apart from plumbing) in one
place, in `LinkHints.activateMode()`. The link-hints mode itself does
not know anything about count handling.
Serious bug:
- Using `Escape` to exit does not cancel the repeat!
Fixes #1289.
Closes #1291.
|
|
|
|
Add a logging page...
|
|
I am now of the opinion that we should not do this within Vimium, as:
- better solutions exist externally, and
- it's better to not have to maintain this.
|
|
This tweaks @mrmr1993's logging ideas discussed in #1629:
- Do not generate log entries from the logging page itself.
- Use the logger for *all* logging (including from `commands.coffee`, and from `bgLog`).
@mrmr1993's original idea is 91fb337c9d92f6291ef42c55c4d29ca35b710203.
|
|
|
|
|
|
This reverts commit e975633f3ee8da9e01c332b2dcdb8422d5f941d8.
|
|
This re-enables edit-mode (`gv`). The code for this has been present in
`master` for quite some time, but has been disabled.
|
|
These seem to be working fine, we can commit to them.
|
|
|
|
Rework to make match counting code for searches more DRY and easier to read
|
