Vimium: Exclude all keys except ____

[truth1ness]

You can easily disable All Keys or Individual Keys for a site, it's difficult to disable All Keys Except Keys x y z. For example, mail.google.com has all keys disabled by default. I would like to use the "f" command from vimium in Gmail. How would I do this? I would have to copy every single Gmail shortcut into the box and take out f which seems very tedious and inneficient.

A better method would be to put a plus sign in front of the keys you want to use from Vimium. ie "+f" would mean "Keep disabling all keys but allow 'f' from Vimium to be used".

[dradetsky]

I just did exactly this 3 minutes ago. I went through the list of shortcuts and set the gmail-excluded keys to jkhlgGzduryivVabceoOTbB[]m`nNHLKJtxXW<>? (this may not work for you; i've already made other config changes)

I'm not sure OP's proposed solution is the best though. A simpler solution that would cover most cases and not require a bunch of parsing code is: have a switch which changes the field from 'disable these keys' to 'only enable these keys'. That's more the kind of thing you could do in an hour if you knew the vimium codebase.

[mrmr1993]

Some considerations:

• Does this disable keys with modifiers?
  
  
  
  • If so, there'd be no way to re-enable them; we currently don't recognise these in the passkeys field (although #1368 could be refreshed to fix that).
  
  
  • If not, how do we communicate this concisely to users so they're not taken by surprise?
  
  
• If we use a + before exclusive keys, how do you disable a mapping on +?
• How do we give users this choice on each rule (and allow them to see what choice they've already made) clearly without overrunning the limited space in the icon popup?
  
  
  
  • Maybe a <select> with "disable" and "allow only" as options? Would that be too big?
  
  
• Would a more powerful text-based config like the one in #1188 be an acceptable/good/better alternative?

The actual backend code changes should be reasonably easy, very little would need to change there to support this.

[mrmr1993]

i'm happy for the relevant feature to ignore mod keys entirely

But is this the right thing to do? Personally I'd feel happier landing #1368 (I'll ping Steve and see if that's a possibility) and making the feature "only the keys and combinations in the passkeys field will be recognised by Vimium", so we don't take anyone by surprise.

one checkbox labelled 'invert' above, possibly with a 'wtf is this shit?' link to documentation.

For the most part people won't read the documentation, so the UI has to be pretty self-explainatory. I'll try it with an 'invert' checkbox when I get round to doing this.

it would be a way-more-complicated and not-clearly-required alternative.

Agreed. I'd wanted it a few times to _change_ some mappings on pages where our and the page's mappings overlap, and _both_ are useful — but it's probably overkill here.

[dradetsky]

1. maybe it's not, but i don't see why we can't start out by supporting
   non-mod keys and then add support for modkeys later.
2. we can disable the checkbox and require you to enable it via a setting,
   but in general i don't agree. we're not talking about software for
   everyone. this is a program for people who are upset their browser isn't
   enough like vim. they have higher-than-average tolerance for reading
   documentation.

On Thu, May 7, 2015 at 2:19 PM, Matthew Ryan [email protected]
wrote:

i'm happy for the relevant feature to ignore mod keys entirely

But is this the right thing to do? Personally I'd feel happier landing

1368 https://github.com/philc/vimium/pull/1368 (I'll ping Steve and

see if that's a possibility) and making the feature "only the keys and
combinations in the passkeys field will be recognised by Vimium", so we
don't take anyone by surprise.

one checkbox labelled 'invert' above, possibly with a 'wtf is this shit?'
link to documentation.

For the most part people won't read the documentation, so the UI has to be
pretty self-explainatory. I'll try it with an 'invert' checkbox when I get
round to doing this.

it would be a way-more-complicated and not-clearly-required alternative.

Agreed. I'd wanted it a few times to _change_ some mappings on pages
where our and the page's mappings overlap, and _both_ are useful — but
it's probably overkill here.

—
Reply to this email directly or view it on GitHub
https://github.com/philc/vimium/issues/1560#issuecomment-100022074.

[mrmr1993]

This isn't my project, and I'm not an official contributer, so I'm just trying to keep within the design goals with this feature. But this might be a good candidate for Vimium Labs (#1542) while the details are worked out.

[smblott-github]

On the idea of an exclude/include toggle... Would that (re-)introduce the issue that the ordering of multiple matching rules would matter?

[mrmr1993]

Would that (re-)introduce the issue that the ordering of multiple matching rules would matter?

If we take them as "disable" vs "allow only", then we could apply all the "allow only" rules first and subtract the "disabled" rules from the result, so the order shouldn't matter.

[dradetsky]

I'm not familiar with the previous discussion of the issue, but can you
think of any reason why specifying a disable rule and an allow-only rule
for the same url isn't a user error? I would think the correct thing to do
would be to warn the user that they had done something bizarre, and then
either

a. order them to fix it.
b. resolve it by ignoring the disable rule.
c. resolve it as Matthew suggests.

I mean, I suppose _maybe_ a user wants to ignore W for all google apps, but
not other urls, and then additionally wants to enable only f on gmail, or
something, but this seems weird. But if we're allowing for strange
possibilities, I might want to disable W on all google apps _except_ gmail,
and also enable f in gmail.

I suppose it wouldn't be too much additional development work to make the
resolution rule configurable (compared to parsing a key-specification
syntax or a more complicated config file), But (b) still seems like the
best solution to me. When I say "allow only" I probably want "allow
exactly."

Can anyone think of a realistic counterexample to the above? Maybe "I never
want to run certain command on https urls" or something? I dunno.
only=exactly seems best to me.

On Thu, May 7, 2015 at 9:08 PM, Matthew Ryan [email protected]
wrote:

Would that (re-)introduce the issue that the ordering of multiple matching
rules would matter?

If we take them as "disable" vs "allow only", then we could apply all the
"allow only" rules first and subtract the "disabled" rules from the result,
so the order shouldn't matter.

—
Reply to this email directly or view it on GitHub
https://github.com/philc/vimium/issues/1560#issuecomment-100096596.

[mrmr1993]

can you think of any reason why specifying a disable rule and an allow-only rule for the same url isn't a user error?

Seems entirely reasonable when a user only wants some keys enabled for a whole site, and further wants to drop some keys for a specific page/part of the site. For example:

allow only:

https?://your.domain.tld/* fJKjki

disable:

https?://your.domain.tld/a-particular-page jk

[dradetsky]

oh yeah

On Fri, May 8, 2015 at 8:46 PM, Matthew Ryan [email protected]
wrote:

can you think of any reason why specifying a disable rule and an
allow-only rule for the same url isn't a user error?

Seems entirely reasonable when a user only wants some keys enabled for a
whole site, and further wants to drop some keys for a specific page/part of
the site. For example:

allow only:

https?://your.domain.tld/* fJKjki

disable:

https?://your.domain.tld/a-particular-page jk

—
Reply to this email directly or view it on GitHub
https://github.com/philc/vimium/issues/1560#issuecomment-100421213.

[christianrondeau]

A good use case for this is using JIRA. I use most shortcuts for JIRA (which is a lot), but I'd still like o to search a new tab, and f to follow links. I can type the whole alphabet in the box and that's ok, but a reverse rule would be simpler :)

[afilp]

@smblott-github Can you please revise this? I also have similar needs, like using just the "f" key on some websites that have many key shortcuts on their own (JIRA, GMAIL, YOUTUBE, etc.).

Thanks a lot!

[DamirCiganovic-Jankovic]

Please do this, I would like to use Vimium only for "f" functionallity, as I already know many chrome shortcuts, this is the only thing I need

[smblott-github]

@DamirCiganovic-Jankovic. You can unmap the keys you never use on the options page.

[mgalgs]

@smblott-github I see this was closed due to lack of interest. Is there any chance of reopening this if enough interest is generated? 😄

To add my own personal story, I used Vimium faithfully for years until about 2 years ago when I realized that _most_ of the sites I used most often (gmail, github, reviewable) had too many clashing shortcuts. So I ended up having Vimium disabled on most sites I used, so I just ditched Vimium. It would be fantastic if I could just whitelist a few of the most common Vimium shortcuts on those sites (f would be top of the list, of course).

_{(Future readers, please give a thumbs up on the top-level comment on this thread to register your interest!)}

[gdh1995]

Seems #3272 also reports this problem, and there're quite a few similar issues. Is there someone interested in my idea in https://github.com/philc/vimium/issues/3272#issuecomment-475296695?

[MikeMajara]

I find this an essential feature and think this should be reopened. I am glad to go through the code but did not have the time yet. So, here is the workaround I'll try to use to avoid all the clashing while not having to completely disable vimium all over the place.

Here are all the keys that vimium uses, to my best of knowledge -
with spaces: ? h j k l g G d r s f F o O b B J K 0 $ ^ y t x X T W p m a A ` i u U e E z H L v V
trimmed: ?hjklgGdrsfFoObBJK0$^ytxXTWpmaA`iuUeEzHLvV

1. Go to your fav text editor (e.g. Vscode)
2. paste the string
3. search and remove the keys you want to enable in Vimium.
4. Paste whats left of the string as an exclude pattern in Vimium pop up