Acabo de hacer exactamente esto hace 3 minutos. Revisé la lista de accesos directos y configuré las claves excluidas de Gmail en jkhlgGzduryivVabceoOTbB[]m`nNHLKJtxXW<>? (Es posible que esto no funcione para usted; ya he realizado otros cambios de configuración)

Sin embargo, no estoy seguro de que la solución propuesta por OP sea la mejor. Una solución más simple que cubriría la mayoría de los casos y no requeriría un montón de código de análisis es: tener un interruptor que cambie el campo de 'deshabilitar estas teclas' a 'solo habilitar estas teclas'. Ese es más el tipo de cosas que podrías hacer en una hora si conocieras el código base de vimium.

Algunas consideraciones:

• ¿Esto deshabilita las teclas con modificadores?
  
  
  
  • Si es así, no habría forma de volver a habilitarlos; actualmente no los reconocemos en el campo de claves de paso (aunque #1368 podría actualizarse para solucionarlo).
  
  
  • Si no es así, ¿cómo comunicamos esto de manera concisa a los usuarios para que no se sorprendan?
  
  
• Si usamos un + antes de las claves exclusivas, ¿cómo se deshabilita una asignación en + ?
• ¿Cómo les damos a los usuarios esta opción en cada regla (y les permitimos ver qué elección ya han hecho) claramente sin sobrepasar el espacio limitado en el icono emergente?
  
  
  
  • ¿Quizás un <select> con "deshabilitar" y "permitir solo" como opciones? ¿Sería demasiado grande?
  
  
• ¿Sería una alternativa aceptable/buena/mejor una configuración basada en texto más potente como la del n.º 1188?

Los cambios reales en el código de back-end deberían ser razonablemente fáciles, muy poco tendría que cambiar allí para admitir esto.

1. De hecho, me olvidé por completo de las teclas de modulación, tan bien ubicadas. estoy feliz
   para que la característica relevante ignore las teclas de mod por completo. tendencia en aplicaciones web
   parece inclinarse hacia las combinaciones de teclas estilo vim de todos modos, así que ahí es donde necesitamos
   para evitar enfrentamientos.
2. esta es otra gran razón para no usar la sintaxis +. o al menos no hasta
   un usuario tiene un caso de uso real.
3. una casilla de verificación etiquetada como 'invertir' arriba, posiblemente con un 'wtf es esto
   ¿mierda?' enlace a la documentación.
4. sería una alternativa mucho más complicada y no claramente requerida.
   "Quiero usar solo algunas funciones de vimium en gmail/twitter/other-app" es
   probablemente algo que muchos usuarios avanzados querrían (ya tenemos 2; y
   el total no es enorme para empezar).

No me opongo a la configuración de texto elegante per se, pero ¿hay una característica más simple?
solicitud que cubre el 90% de los casos? dado que le estoy preguntando a alguien que he
nunca se reunió para escribir código para mí (hasta donde él sabe) gratis, siento que es
me corresponde verificar.

El miércoles 6 de mayo de 2015 a las 6:20 p. m., Matthew Ryan [email protected]
escribió:

Algunas consideraciones:

• ¿Esto deshabilita las teclas con modificadores?
  
  
  
  • Si es así, no habría forma de volver a habilitarlos; actualmente no
    
    reconozca estos en el campo de claves de acceso (aunque # 1368
    
    https://github.com/philc/vimium/pull/1368 podría actualizarse a
    
    Arregla eso).
  
  
  • Si no, ¿cómo comunicamos esto de manera concisa a los usuarios para que estén
    
    no tomado por sorpresa?
  
  
  • Si usamos un + antes de las teclas exclusivas, ¿cómo se desactiva un mapeo?
    
    en +?
  
  
• ¿Cómo les damos a los usuarios esta opción en cada regla (y les permitimos ver
  qué elección ya han hecho) claramente sin sobrepasar el límite
  espacio en el icono emergente?
  
  
  
  • Tal vez uncon "deshabilitar" y "permitir solo" como opciones?
    
    ¿Sería demasiado grande?
  
  
  • ¿Habría una configuración basada en texto más poderosa como la del #1188?
    
    https://github.com/philc/vimium/issues/1188 ser un
    
    aceptable/buena/mejor alternativa?
  
  

Los cambios reales en el código de fondo deberían ser razonablemente fáciles, muy poco
tendría que cambiar allí para apoyar esto.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/philc/vimium/issues/1560#issuecomment-99668372 .

Estoy feliz por la función relevante para ignorar las teclas de mod por completo

Pero, ¿es esto lo correcto? Personalmente, me sentiría más feliz aterrizando en el n.º 1368 (hablaré con Steve y veré si es una posibilidad) y creando la característica "Solo las teclas y combinaciones en el campo de claves de paso serán reconocidas por Vimium", para que no tomemos a nadie. por sorpresa.

una casilla de verificación etiquetada como 'invertir' arriba, posiblemente con un 'qué mierda es esto?' enlace a la documentación.

En su mayor parte, las personas no leerán la documentación, por lo que la interfaz de usuario debe explicarse por sí misma. Lo intentaré con una casilla de verificación 'invertir' cuando llegue a hacer esto.

sería una alternativa mucho más complicada y no claramente requerida.

Acordado. Quería que varias veces _cambiara_ algunas asignaciones en páginas donde la nuestra y la de la página se superponen, y _ambas_ son útiles, pero probablemente sea exagerado aquí.

1. tal vez no lo sea, pero no veo por qué no podemos empezar apoyando
   teclas no mod y luego agregue soporte para modkeys más tarde.
2. podemos deshabilitar la casilla de verificación y pedirle que la habilite a través de una configuración,
   pero en general no estoy de acuerdo. no estamos hablando de software para
   todos. este es un programa para personas que están molestas porque su navegador no funciona
   lo suficiente como vim. tienen una tolerancia a la lectura superior a la media
   documentación.

El jueves 7 de mayo de 2015 a las 14:19, Matthew Ryan [email protected]
escribió:

Estoy feliz por la función relevante para ignorar las teclas de mod por completo

Pero, ¿es esto lo correcto? Personalmente me sentiría más feliz aterrizando

1368 https://github.com/philc/vimium/pull/1368 (Haré ping a Steve y

ver si esa es una posibilidad) y hacer que la función "solo las teclas y
Vimium reconocerá las combinaciones en el campo de claves de acceso", por lo que
no tome a nadie por sorpresa.

una casilla de verificación etiquetada como 'invertir' arriba, posiblemente con un 'qué mierda es esto?'
enlace a la documentación.

En su mayor parte, las personas no leerán la documentación, por lo que la interfaz de usuario debe ser
bastante autoexplicativo. Lo intentaré con una casilla de verificación 'invertir' cuando tenga
redondo para hacer esto.

sería una alternativa mucho más complicada y no claramente requerida.

Acordado. Lo quería varias veces para _cambiar_ algunas asignaciones en las páginas
donde nuestras asignaciones y las de la página se superponen, y _ambas_ son útiles, pero
probablemente sea exagerado aquí.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/philc/vimium/issues/1560#issuecomment-100022074 .

Este no es mi proyecto, y no soy un contribuyente oficial, así que solo trato de mantenerme dentro de los objetivos de diseño con esta función. Pero este podría ser un buen candidato para Vimium Labs (#1542) mientras se resuelven los detalles.

Sobre la idea de un conmutador de exclusión/inclusión... ¿(Re)introduciría eso el problema de que el orden de múltiples reglas de coincidencia sería importante?

¿(Re)introduciría eso el problema de que el orden de múltiples reglas de coincidencia sería importante?

Si los tomamos como "deshabilitar" frente a "solo permitir", entonces podríamos aplicar todas las reglas de "solo permitir" primero y restar las reglas "deshabilitadas" del resultado, por lo que el orden no debería importar.

No estoy familiarizado con la discusión anterior sobre el tema, pero ¿puede
Piense en alguna razón por la cual especificar una regla de inhabilitación y una regla de solo permitir
para la misma url no es un error de usuario? creo que es lo correcto
sería advertir al usuario que había hecho algo extraño, y luego
cualquiera

una. ordenarles que lo arreglen.
B. resuélvalo ignorando la regla de desactivación.
C. resolverlo como sugiere Matthew.

Quiero decir, supongo que _tal vez_ un usuario quiere ignorar W para todas las aplicaciones de Google, pero
no otras URL, y además quiere habilitar solo f en gmail, o
algo, pero esto parece raro. Pero si estamos permitiendo cosas extrañas
posibilidades, es posible que desee deshabilitar W en todas las aplicaciones de Google _excepto_ gmail,
y también habilite f en gmail.

Supongo que no sería demasiado trabajo de desarrollo adicional hacer que el
regla de resolución configurable (en comparación con el análisis de una especificación de clave)
sintaxis o un archivo de configuración más complicado), pero (b) todavía parece el
la mejor solución para mí. Cuando digo "permitir solo" probablemente quiero "permitir
exactamente."

¿Alguien puede pensar en un contraejemplo realista al anterior? Tal vez "Yo nunca
¿Quieres ejecutar cierto comando en urls https" o algo así? No lo sé.
only=exactamente me parece lo mejor.

El jueves 7 de mayo de 2015 a las 21:08, Matthew Ryan [email protected]
escribió:

¿(Re)introduciría eso el problema de que el ordenamiento de coincidencias múltiples
importan las reglas?

Si los tomamos como "deshabilitar" frente a "permitir solo", entonces podríamos aplicar todos los
reglas "permitir solo" primero y restar las reglas "deshabilitadas" del resultado,
así que el orden no debería importar.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/philc/vimium/issues/1560#issuecomment-100096596 .

¿Puedes pensar en alguna razón por la cual especificar una regla de inhabilitación y una regla de solo permitir para la misma URL no es un error de usuario?

Parece completamente razonable cuando un usuario solo quiere que se habiliten algunas claves para un sitio completo y, además, desea eliminar algunas claves para una página o parte específica del sitio. Por ejemplo:

Permitir solo:

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

desactivar:

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

Oh sí

El viernes 8 de mayo de 2015 a las 20:46, Matthew Ryan [email protected]
escribió:

¿Se le ocurre alguna razón por la que especificar una regla de desactivación y una
¿La regla de solo permitir para la misma URL no es un error de usuario?

Parece completamente razonable cuando un usuario solo quiere que algunas teclas estén habilitadas para un
todo el sitio, y además quiere soltar algunas claves para una página específica/parte de
el sitio. Por ejemplo:

Permitir solo:

https?://su.dominio.tld/* fJKjki

desactivar:

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

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/philc/vimium/issues/1560#issuecomment-100421213 .

Un buen caso de uso para esto es usar JIRA. Utilizo la mayoría de los accesos directos para JIRA (que son muchos), pero aún me gustaría buscar una nueva pestaña y seguir los enlaces. Puedo escribir todo el alfabeto en el cuadro y está bien, pero una regla inversa sería más simple :)

@ smblott-github ¿Puedes revisar esto? También tengo necesidades similares, como usar solo la tecla "f" en algunos sitios web que tienen muchos atajos de teclado propios (JIRA, GMAIL, YOUTUBE, etc.).

¡Muchas gracias!

Haga esto, me gustaría usar Vimium solo para la funcionalidad "f", ya que conozco muchos accesos directos de Chrome, esto es lo único que necesito

@DamirCiganovic-Jankovic. Puede desasignar las teclas que nunca usa en la página de opciones.

@ smblott-github Veo que esto se cerró debido a la falta de interés. ¿Hay alguna posibilidad de reabrir esto si se genera suficiente interés? 😄

Para agregar mi propia historia personal, usé Vimium fielmente durante años hasta hace aproximadamente 2 años cuando me di cuenta de que _la mayoría_ de los sitios que usaba con más frecuencia (gmail, github, revisable) tenían demasiados accesos directos que chocaban. Así que terminé con Vimium deshabilitado en la mayoría de los sitios que usé, así que dejé Vimium. Sería fantástico si pudiera incluir en la lista blanca algunos de los accesos directos de Vimium más comunes en esos sitios ( f sería el primero de la lista, por supuesto).

_{(¡Lectores futuros, den un pulgar hacia arriba en el comentario de nivel superior en este hilo para registrar su interés!)}

Parece que el n.º 3272 también informa de este problema, y ​​hay bastantes problemas similares. ¿Hay alguien interesado en mi idea en https://github.com/philc/vimium/issues/3272#issuecomment -475296695?

Considero que esta es una característica esencial y creo que debería reabrirse. Me alegro de revisar el código, pero aún no tuve tiempo. Entonces, aquí está la solución que intentaré usar para evitar todos los choques sin tener que deshabilitar completamente vimium en todo el lugar.

Aquí están todas las claves que usa vimium, según mi leal saber y entender:
con espacios : ? hjklg G drsf F o O b BJK 0 $ ^ ytx XTW pma A ` iu U e E z HL v V
recortado : ?hjklgGdrsfFoObBJK0$^ytxXTWpmaA`iuUeEzHLvV

1. Vaya a su editor de texto favorito (por ejemplo, Vscode)
2. pegar la cadena
3. busque y elimine las claves que desea habilitar en Vimium.
4. Pegue lo que queda de la cadena como un patrón de exclusión en la ventana emergente de Vimium