philc / philc/vimium

Consider adding a chrome.commands command for nextTab, previousTab

Open
#4,419 1 comment 0 reactions 0 assignees View on GitHub

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:

  1. 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?
  2. Which Vimium commands are valuable to expose in this way, besides next and prev tab?
  3. Is there any downside to implementing this? Is there any ongoing maintenance overhead?
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.