philc / vimium

The hacker's browser.

Home Page:https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Consider adding a chrome.commands command for nextTab, previousTab

philc opened this issue · comments

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?
  1. because some browsers don't support remapping shortcuts natively (at least not easily on their UI)
    1. I personally like "binding multiple keys to a same function", so that I can use my left hand or right hand to trigger it - which hand to use depends on which one is not occupied.
  1. I suggest these:
    1. createTab: create a tab of Vimium's new tab url, and then the keyboard focus may not be moved to address bar any more
    1. previousTab and nextTab: switch among all types and statuses of tabs
    1. if we want to add more, then reloadTab is also useful. For example, it may refresh a broken page
  1. Maybe quite little; this API is very very stable - no function updates since Chrome 35, as said in https://developer.chrome.com/docs/extensions/reference/api/commands
  2. maybe a doc to explain it could help