| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Chrome stop using <backspace> to go back, but some still wants this
feature.
This should fix #2207 and #2214.
|
|
|
|
It reads weird on the helpd dialog if we don't put the full-page and
half-page commands in a similar order.
|
|
- Re-order commands such that we keep like with like, and have the more
important commands nearer the top.
- Re-word some command descriptions such that we use the same words for
the the same thing consistently.
- Move "View Source" to the "Miscellaneous" category.
- Make some commands "advanced commands".
|
|
Replaces #2037.
|
|
|
|
|
|
This command (LinkHints.activateModeToCopyLinkUrl) has been in the wrong
spot for quite some time. This just moves it to be with the other
link-hints commands.
|
|
We pass the count to *all* front-end commands. All of the commands
which don't use a count, just ignore it.
|
|
With this change, now *every* front-end command either accepts a count
argument, or or it doesn't accept a count at all.
|
|
"description" is the first element here, not all elements. So
"descriptor" is a better name.
|
|
|
|
|
|
Oversight from #2022.
|
|
This generalises the mechanism by which commands are always run in the
tab's main/top frame. Currently, that's just the Vomnibar.
This is a precursor to moving other UI components to the main/top frame.
It should be fairly trivial to move the help page to the main frame.
The HUD might be trickier.
Mention: @mrmr1993.
|
|
If we just use the name `background` instead of `isBackgroundCommand`,
then we can simplify the building of registry entries.
This is preparitory to adding a new registryEntry field: topFrame;
initially just for the Vomnibar, but thereafter for other UI components.
|
|
|
|
|
|
|
|
- simplify pass key condition
- don't keep key-parsing Regexp in memory
- we should reset the key state when the pass keys change
|
|
|
|
|
|
|
|
... We need it for the help page.
|
|
|
|
- There's no need to keep `@keyToCommandRegistry`; it's regenerated
whenever it's needed.
|
|
With:
map g something
map gg somethingElse
The mapping for "g" always takes priority, regardless of the order in
which they're encountered in `@keyToCommandRegistry`.
|
|
|
|
|
|
|
|
|
|
|
|
The default (for when no options are provided) is of the wrong type.
This works as is, but should really be fixed -- as here.
|
|
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).
|
|
We need to multiply by `count=N` *before* checking `repeatLimit`.
Tweaks #2001.
|
|
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.
|
|
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.
|
|
Make `moveToNewWindow` accept a count.
|
|
|
|
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.
|
|
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.)
|
