Vimium: Excluir todas as chaves, exceto ____

Criado em 13 abr. 2015  ·  18Comentários  ·  Fonte: philc/vimium

Você pode facilmente desabilitar todas as chaves ou chaves individuais para um site, é difícil desabilitar todas as chaves, exceto as chaves xy z. Por exemplo, mail.google.com tem todas as chaves desativadas por padrão. Gostaria de usar o comando "f" do vimium no Gmail. Como eu faria isso? Eu teria que copiar todos os atalhos do Gmail para a caixa e tirar f, o que parece muito tedioso e ineficaz.

Um método melhor seria colocar um sinal de mais na frente das teclas que você deseja usar no Vimium. ou seja, "+f" significaria "Continue desabilitando todas as teclas, mas permita que 'f' do Vimium seja usado".

closing-lack-of-interest

Comentários muito úteis

Um bom caso de uso para isso é usar o JIRA. Eu uso a maioria dos atalhos para o JIRA (o que é muito), mas ainda gostaria o para pesquisar uma nova guia ef para seguir os links. Eu posso digitar o alfabeto inteiro na caixa e tudo bem, mas uma regra inversa seria mais simples :)

Todos 18 comentários

Eu fiz exatamente isso 3 minutos atrás. Percorri a lista de atalhos e defini as chaves excluídas do Gmail para jkhlgGzduryivVabceoOTbB[]m`nNHLKJtxXW<>? (isso pode não funcionar para você; eu já fiz outras alterações de configuração)

Não tenho certeza se a solução proposta do OP é a melhor. Uma solução mais simples que cobriria a maioria dos casos e não exigiria um monte de código de análise é: ter um switch que altere o campo de 'desabilitar essas chaves' para 'somente habilitar essas chaves'. Isso é mais o tipo de coisa que você poderia fazer em uma hora se você conhecesse a base de código do vimium.

Algumas considerações:

  • Isso desativa as teclas com modificadores?

    • Nesse caso, não haveria como reativá-los; atualmente não os reconhecemos no campo de senhas (embora o #1368 possa ser atualizado para corrigir isso).

    • Se não, como comunicamos isso de forma concisa aos usuários para que eles não sejam pegos de surpresa?

  • Se usarmos + antes de chaves exclusivas, como você desabilita um mapeamento em + ?
  • Como damos aos usuários essa escolha em cada regra (e permitimos que eles vejam qual escolha eles já fizeram) claramente sem ultrapassar o espaço limitado no pop-up do ícone?

    • Talvez um <select> com "desativar" e "permitir apenas" como opções? Seria muito grande?

  • Uma configuração baseada em texto mais poderosa como a de #1188 seria uma alternativa aceitável/boa/melhor?

As alterações reais do código de back-end devem ser razoavelmente fáceis, muito pouco precisaria ser alterado para oferecer suporte a isso.

  1. na verdade, esqueci completamente das teclas mod, tão bem localizadas. Eu estou feliz
    para que o recurso relevante ignore totalmente as teclas de modificação. tendência em aplicativos da web
    parece ser para combinações de teclas no estilo vim de qualquer maneira, então é aí que precisamos
    para evitar confrontos.
  2. este é outro grande motivo para não usar a sintaxe +. ou pelo menos não até
    um usuário tem um caso de uso real.
  3. uma caixa de seleção rotulada 'inverter' acima, possivelmente com um 'wtf é isso
    merda?' link para documentação.
  4. seria uma alternativa muito mais complicada e não claramente exigida.
    "Eu quero usar apenas algumas funções do vimium no gmail/twitter/other-app" é
    provavelmente algo que muitos usuários avançados gostariam (já temos 2; e
    total não é enorme para começar).

Eu não me oponho à configuração de texto sofisticada em si, mas existe um recurso mais simples
pedido que cobre 90% dos casos? dado que estou perguntando a alguém que eu
nunca encontrei para escrever código para mim (até onde ele sabe) de graça, eu sinto que é
incumbe a mim verificar.

Na quarta-feira, 6 de maio de 2015 às 18h20, Matthew Ryan [email protected]
escreveu:

Algumas considerações:

  • Isso desativa as teclas com modificadores?

    • Nesse caso, não haveria como reativá-los; nós atualmente não

      reconheça-os no campo das chaves de acesso (embora #1368

      https://github.com/philc/vimium/pull/1368 pode ser atualizado para

      Conserte isso).

    • Se não, como comunicamos isso de forma concisa aos usuários para que eles

      não foi pego de surpresa?

    • Se usarmos um + antes de chaves exclusivas, como você desabilita um mapeamento

      em +?

  • Como damos aos usuários essa opção em cada regra (e permitimos que eles vejam
    que escolha eles já fizeram) claramente sem ultrapassar o limite
    espaço no pop-up do ícone?

    • Talvez um

    • Uma configuração baseada em texto mais poderosa como a do #1188

      https://github.com/philc/vimium/issues/1188 seja um

      alternativa aceitável/boa/melhor?

As alterações reais do código de back-end devem ser razoavelmente fáceis, muito pouco
precisaria mudar lá para suportar isso.


Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -99668372.

estou feliz pelo recurso relevante para ignorar totalmente as teclas mod

Mas isso é a coisa certa a fazer? Pessoalmente, eu me sentiria mais feliz com o #1368 (vou dar um ping no Steve e ver se isso é uma possibilidade) e fazer o recurso "somente as chaves e combinações no campo de senhas serão reconhecidas pelo Vimium", para que não levemos ninguém por surpresa.

uma caixa de seleção rotulada 'inverter' acima, possivelmente com um 'wtf é essa merda?' link para documentação.

Na maioria das vezes, as pessoas não vão ler a documentação, então a interface do usuário deve ser bastante autoexplicativa. Vou tentar com uma caixa de seleção 'inverter' quando conseguir fazer isso.

seria uma alternativa muito mais complicada e não claramente exigida.

Acordado. Eu queria algumas vezes para _alterar_ alguns mapeamentos em páginas onde nossos mapeamentos e os da página se sobrepõem, e _ambos_ são úteis - mas provavelmente é um exagero aqui.

  1. talvez não seja, mas não vejo por que não podemos começar apoiando
    chaves não mod e, em seguida, adicione suporte para modkeys posteriormente.
  2. podemos desativar a caixa de seleção e exigir que você a ative por meio de uma configuração,
    mas em geral não concordo. não estamos falando de software para
    todo o mundo. este é um programa para pessoas que estão chateadas porque seu navegador não está
    o suficiente como vim. eles têm tolerância acima da média para a leitura
    documentação.

Na quinta-feira, 7 de maio de 2015 às 14h19, Matthew Ryan [email protected]
escreveu:

estou feliz pelo recurso relevante para ignorar totalmente as teclas mod

Mas isso é a coisa certa a fazer? Pessoalmente, eu me sentiria mais feliz pousando

1368 https://github.com/philc/vimium/pull/1368 (vou pingar Steve e

veja se isso é uma possibilidade) e tornando o recurso "somente as teclas e
combinações no campo de senhas serão reconhecidas pelo Vimium", então
não pegue ninguém de surpresa.

uma caixa de seleção rotulada 'inverter' acima, possivelmente com um 'wtf é essa merda?'
link para documentação.

Na maioria das vezes, as pessoas não vão ler a documentação, então a interface do usuário deve ser
bastante autoexplicativo. Vou tentar com uma caixa de seleção 'inverter' quando chegar
volta para fazer isso.

seria uma alternativa muito mais complicada e não claramente exigida.

Acordado. Eu queria algumas vezes _alterar_ alguns mapeamentos nas páginas
onde os mapeamentos nosso e da página se sobrepõem e _ambos_ são úteis - mas
é provavelmente um exagero aqui.


Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100022074.

Este não é meu projeto, e eu não sou um contribuidor oficial, então estou apenas tentando manter os objetivos de design com esse recurso. Mas este pode ser um bom candidato para o Vimium Labs (#1542) enquanto os detalhes são trabalhados.

Sobre a ideia de uma alternância de exclusão/inclusão... Isso (re-)introduziria a questão de que a ordenação de várias regras de correspondência seria importante?

Isso (re) introduziria a questão de que a ordenação de várias regras de correspondência seria importante?

Se as considerarmos como "desativar" versus "somente permitir", poderíamos aplicar todas as regras "somente permitir" primeiro e subtrair as regras "desativadas" do resultado, portanto, a ordem não deveria importar.

Não estou familiarizado com a discussão anterior sobre o assunto, mas você pode
pense em qualquer motivo para especificar uma regra de desabilitação e uma regra de permissão
para o mesmo URL não é um erro do usuário? Eu acho que a coisa certa a fazer
seria avisar o usuário que ele havia feito algo bizarro, e então
qualquer

uma. ordená-los para corrigi-lo.
b. resolva-o ignorando a regra de desativação.
c. resolvê-lo como Matthew sugere.

Quero dizer, suponho que _talvez_ um usuário queira ignorar W para todos os aplicativos do Google, mas
não outros URLs e, além disso, deseja ativar apenas f no gmail ou
alguma coisa, mas isso parece estranho. Mas se estamos permitindo coisas estranhas
possibilidades, talvez queira desabilitar o W em todos os aplicativos do Google _exceto_ gmail,
e também habilite f no gmail.

Suponho que não seria muito trabalho de desenvolvimento adicional para tornar o
regra de resolução configurável (em comparação com a análise de uma especificação de chave
sintaxe ou um arquivo de configuração mais complicado), mas (b) ainda parece o
melhor solução para mim. Quando digo "permitir apenas" provavelmente quero "permitir
exatamente."

Alguém pode pensar em um contra-exemplo realista para o acima? Talvez "eu nunca
deseja executar determinado comando em URLs https" ou algo assim? Não sei.
only=exatamente parece melhor para mim.

Na quinta-feira, 7 de maio de 2015 às 21h08, Matthew Ryan [email protected]
escreveu:

Isso (re) introduziria o problema de que a ordenação de correspondência múltipla
regras importariam?

Se os considerarmos como "desativar" versus "somente permitir", poderíamos aplicar todos os
"permitir apenas" regras primeiro e subtrair as regras "desativadas" do resultado,
então a ordem não deveria importar.


Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100096596.

você pode pensar em algum motivo pelo qual especificar uma regra de desabilitação e uma regra de permissão para o mesmo URL não seja um erro do usuário?

Parece totalmente razoável quando um usuário deseja apenas algumas chaves habilitadas para um site inteiro e ainda deseja descartar algumas chaves para uma página/parte específica do site. Por exemplo:

permitir apenas:

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

desabilitar:

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

Oh sim

Na sexta-feira, 8 de maio de 2015 às 20h46, Matthew Ryan [email protected]
escreveu:

você pode pensar em alguma razão para especificar uma regra de desabilitação e um
regra de permissão para o mesmo URL não é um erro do usuário?

Parece totalmente razoável quando um usuário quer apenas algumas chaves habilitadas para um
todo o site e ainda deseja descartar algumas chaves para uma página/parte específica de
o site. Por exemplo:

permitir apenas:

https?://seu.domínio.tld/* fJKjki

desabilitar:

https?://seu.domínio.tld/a-página-particular jk


Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100421213.

Um bom caso de uso para isso é usar o JIRA. Eu uso a maioria dos atalhos para o JIRA (o que é muito), mas ainda gostaria o para pesquisar uma nova guia ef para seguir os links. Eu posso digitar o alfabeto inteiro na caixa e tudo bem, mas uma regra inversa seria mais simples :)

@smblott-github Você pode revisar isso? Também tenho necessidades semelhantes, como usar apenas a tecla "f" em alguns sites que possuem muitos atalhos de teclas por conta própria (JIRA, GMAIL, YOUTUBE etc.).

Muito obrigado!

Por favor, faça isso, gostaria de usar o Vimium apenas para a funcionalidade "f", pois já conheço muitos atalhos do chrome, esta é a única coisa que preciso

@DamirCiganovic-Jankovic. Você pode desmapear as teclas que nunca usa na página de opções.

@smblott-github, vejo que isso foi fechado devido à falta de interesse. Existe alguma chance de reabrir isso se houver interesse suficiente? 😄

Para adicionar minha própria história pessoal, usei o Vimium fielmente por anos até cerca de 2 anos atrás, quando percebi que a maioria dos sites que usava com mais frequência (gmail, github, reviewable) tinha muitos atalhos conflitantes. Então acabei desabilitando o Vimium na maioria dos sites que usei, então abandonei o Vimium. Seria fantástico se eu pudesse listar alguns dos atalhos mais comuns do Vimium nesses sites ( f estaria no topo da lista, é claro).

(Futuros leitores, por favor, dê um joinha no comentário de nível superior neste tópico para registrar seu interesse!)

Parece que o nº 3272 também relata esse problema e há alguns problemas semelhantes. Existe alguém interessado na minha ideia em https://github.com/philc/vimium/issues/3272#issuecomment -475296695?

Acho isso uma característica essencial e acho que isso deveria ser reaberto. Estou feliz em passar pelo código, mas ainda não tive tempo. Então, aqui está a solução que tentarei usar para evitar todos os conflitos sem precisar desabilitar completamente o vimium em todo o lugar.

Aqui estão todas as chaves que o vimium usa, até onde eu sei -
com espaços : ? hjklg G drsf F o O b BJK 0 $ ^ ytx XTW pma A ` iu U e E z HL v V
aparado : ?hjklgGdrsfFoObBJK0$^ytxXTWpmaA`iuUeEzHLvV

  1. Vá para o seu editor de texto favorito (por exemplo, Vscode)
  2. cole a corda
  3. pesquise e remova as chaves que você deseja habilitar no Vimium.
  4. Cole o que resta da string como um padrão de exclusão no pop-up do Vimium
Esta página foi útil?
0 / 5 - 0 avaliações