| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
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.)
|
|
Search completion; add support for Qwant completion
|
|
|
|
|
|
|
|
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).
|
|
With #1697, the vomnibar used with a custom-search keyword is not
initially empty (it shows the primary suggestion for the custom search
engine, even if the query is empty). The way things were structured
previously, the user nevertheless had to wait until the history cache
(which was not actually required) had been fetched before the vomnibar
was updated.
This commit just flips things around a bit such that,
- onComplete() is called immediately if the history is not actually
required, and
- the history cache is primed before it is needed, so it will
(hopefully) be available before the user's next keystroke.
This avoids a noticable delay, particularly on start up and with a large
history.
(This is part of a sequence of vomnibar UX tweaks.)
|
