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 Support compound keys (<a-f>, <c-[>, etc.) in passkeys #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 Per-url key mappings #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.

[dradetsky]

1. i actually completely forgot about mod keys, so well-spotted. i'm happy
   for the relevant feature to ignore mod keys entirely. trend on web apps
   seems to be towards vim-style keybindings anyway, so that's where we need
   to avoid clashes.
2. this is another great reason not to use +-syntax. or at least not until
   a user has an actual use-case.
3. one checkbox labelled 'invert' above, possibly with a 'wtf is this
   shit?' link to documentation.
4. it would be a way-more-complicated and not-clearly-required alternative.
   "I want to use only a few vimium functions in gmail/twitter/other-app" is
   probably something lotsa power users would want (we have 2 already; and
   total isn't huge to begin with).

I don't oppose fancy text config per se, but is there a simpler feature
request that covers 90% of the cases? given that i'm asking somebody i've
never met to write code for me for (as far as he knows) free, i feel it's
incumbent upon me to check.

On Wed, May 6, 2015 at 6:20 PM, Matthew Ryan notifications@github.com
wrote:

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 Support compound keys (<a-f>, <c-[>, etc.) in passkeys #1368
    Support compound keys (<a-f>, <c-[>, etc.) in passkeys #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 with "disable" and "allow only" as options? Would that be too big? Would a more powerful text-based config like the one in Per-url key mappings #1188 https://github.com/Per-url key mappings #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. — Reply to this email directly or view it on GitHub https://github.com/Exclude all keys except ____ #1560#issuecomment-99668372.

[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 notifications@github.com
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 #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
#1560 (comment).

[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 notifications@github.com
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
#1560 (comment).

[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 notifications@github.com
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
#1560 (comment).

[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 #3272 (comment)?

[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

[Jasha10]

Here are all the keys that vimium uses, to my best of knowledge

@mikemajara, I've expanded your list to a bigger subset of ascii keys. This way, even if vimium adds more keyboard shortcuts in the future, the list should still be fairly complete.

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

[idontlikecreatingaccounts]

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$^ytxXTWpmaAiuUeEzHLvV

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

Thanks for this, but I also find that a proper 'whitelist/blacklist' feature would be preferrable to copying and pasting a long list of characters into a tiny text box. Especially when Oo & Ff are pretty much always what I want to keep enabled.

[mikemajara]

Just use Vimium-C

[nitayderei]

Instead of going through the list of keys, I configured to unmap all keys and re-map my favorite (f) to ~:

unmapAll
map ` LinkHints.activateMode

It works great for a small number of keys :)

[Susensio]

Instead of going through the list of keys, I configured to unmap all keys and re-map my favorite (f) to ~:

unmapAll
map ` LinkHints.activateMode

It works great for a small number of keys :)

But this works globally, right? I mean, it cannot be applied to only one website.

[nikhilweee]

Came here to show interest about this feature. This would be really helpful.

[Susensio]

I ended up using Vimium C
You can do a negative exclusion with ^.
For example, if I only want to move between tabs in github, I would do something like:

^ J K