Consider adding a chrome.commands command for nextTab, previousTab
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 27k
- Forks
- 2.6k
- PR merge metrics
- No merged PRs in 30d
Description
Vimium can't run on some pages like the chrome store, and URLs which begin with chrome://.
One common case where this becomes annoying is when switching tabs. If you're using Vimium's shortcuts to cycle through tabs, and you hit a tab where Vimium isn't enabled, then you are stuck and have to use the browser's shortcuts for switching tabs.
I don't personally use Vimium's next/previous tab commands. Instead, I've configured system-wide shortcuts which work across all apps which use tabs (every browser, iTerm, Emacs). I've outlined my workflow on the tips and tricks page.
Most people who don't want to do that, we could improve the situation by exposing a command to the chrome extensions system which users can bind for themselves. This would work browser-wide, even if Vimium is not enabled for a given page.
Since the browser's global commands aren't modal, naturally the keybinding can't be J and K as it is in Vimium. I think cmd-j and cmd-j make sense for Mac (ctrl- for Windows and Linux), but cmd-j masks the browsers "Show Downloads" command. And I believe shift-ctrl-J masks the "open Chrome Developer Tools" command on Windows.
So by default, I think Vimium would offer these commands to allow a user to bind them, but not suggest a default binding.
Some questions for discussion:
- Since these browser-level shortcuts aren't modal, and are equivalent to the browser's implementation, does Vimium add any value here? Rather than do this, why don't we just advise users to use their browser's next/prev tab shortcuts, and advise them to change the browser's keybinding if they don't like the default?
- Which Vimium commands are valuable to expose in this way, besides next and prev tab?
- Is there any downside to implementing this? Is there any ongoing maintenance overhead?
- Isn't it strange/confusing that there would be two ways to bind the tab movement commands -- a modal one via Vimium's options page, and a non-modal one via the browser's keyboard shortcuts page for extensions?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing Chrome's extension command system and Vimium's existing next-tab and previous-tab commands. Compare the Vimium options page with the browser's keyboard shortcuts page, then resolve whether browser-wide commands add value and which commands should be exposed. Done means an agreed scope and implementation plan, or the proposal is closed with documented rationale.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100