| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
Specifically, avoid reliance on `chrome.tabs.onSelectionChanged`.
If we merge this and #2006, then we can delete all of the
`chrome.tabs.onSelectionChanged` code.
|
|
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
|
|
|
|
- handle case where there's only one tab
- also focus the selected tab's window
|
|
Implements visitPreviousTab (as discussed in #1955).
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
In #1828, we (I) broke the fact that `gt` and `gT` should be able to
wrap around at the ends (so, for example, `gt` on the right-most tab
should take you to the first).
|
|
`2g0` takes you to the second tab.
`2g$` takes you to the second last tab.
This gives us `gt`/`gT` for relative tab selection and `g0`/`g$` for absolute tab selection.
`<count>` previously had no special meaning for `g0` and `g$`, and it's not clear it could have any other meaning than that implemented here.
Fixes #1298 (kind of).
|
|
Fixes #1814.
(This fixes a problem that was introduced in the "fix" of #1727.)
|
|
This makes global marks use the same code for opening new tabs as other
operations. Thus, the new tab appears in the same position as it would
if it were created, for example, via the vomnibar.
To do this properly, we move the three tab-creating functions into an
object which can be (and is) exported (TabOperations).
Also fixes these three operations such that they all take the same
arguments; that is (request, callback). Not all of these callbacks are
being used. But we should be consistent.
|
|
If the tab is subsequently deleted, then we return to the original tab
(as opposed to the one on its right).
|
|
|
|
... as suggested by @mrmr1993 in #1728.
|
|
|
|
Note. This does not allow tabs to rotate from the left around to the
right, or vice versa. Which means "999<<" moves the current tab all the
way to the left (and similarly to the right).
Fixes #1727 (kind of).
|
|
On the help page, use separate row for very-long bindings.
|
|
|
|
If there are many bindings for a command, then the column layout on the
help page can become out of whack. This commit puts such bindings on a
separate table row which spans all three columns.
(Many bindings for a single command are more likely in light of #1697.)
|
|
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.
|
|
|
|
Direct keyboard access to custom-search engines via keyword flag
|
|
This stops Sync from being referred to from anywhere except
settings.coffee and settings_test.coffee.
|
