Je viens de faire exactement cela il y a 3 minutes. J'ai parcouru la liste des raccourcis et défini les clés exclues de gmail sur jkhlgGzduryivVabceoOTbB[]m`nNHLKJtxXW<> ? (cela peut ne pas fonctionner pour vous ; j'ai déjà apporté d'autres modifications à la configuration)

Je ne suis pas sûr que la solution proposée par OP soit la meilleure. Une solution plus simple qui couvrirait la plupart des cas et ne nécessiterait pas un tas de code d'analyse est la suivante : avoir un commutateur qui change le champ de "désactiver ces touches" à "activer uniquement ces touches". C'est plutôt le genre de chose que vous pourriez faire en une heure si vous connaissiez la base de code vimium.

Quelques considérations :

• Cela désactive-t-il les clés avec des modificateurs ?
  
  
  
  • Si c'est le cas, il n'y aurait aucun moyen de les réactiver ; nous ne les reconnaissons pas actuellement dans le champ des mots de passe (bien que #1368 puisse être actualisé pour résoudre ce problème).
  
  
  • Si ce n'est pas le cas, comment pouvons-nous communiquer cela de manière concise aux utilisateurs afin qu'ils ne soient pas pris par surprise ?
  
  
• Si nous utilisons un + avant les clés exclusives, comment désactiver un mappage sur + ?
• Comment donner aux utilisateurs ce choix sur chaque règle (et leur permettre de voir quel choix ils ont déjà fait) clairement sans dépasser l'espace limité dans la fenêtre contextuelle de l'icône ?
  
  
  
  • Peut-être un <select> avec "désactiver" et "autoriser uniquement" comme options ? Serait-ce trop gros ?
  
  
• Une configuration textuelle plus puissante comme celle du #1188 serait-elle une alternative acceptable/bonne/meilleure ?

Les modifications réelles du code backend devraient être raisonnablement faciles, très peu de choses auraient besoin d'être modifiées pour prendre en charge cela.

1. En fait, j'ai complètement oublié les touches de mod, si bien repérées. je suis heureux
   pour que la fonctionnalité concernée ignore complètement les touches de modification. tendance sur les applications Web
   semble être vers les raccourcis clavier de style vim de toute façon, c'est donc là que nous avons besoin
   pour éviter les heurts.
2. c'est une autre bonne raison de ne pas utiliser la syntaxe +. ou du moins pas avant
   un utilisateur a un cas d'utilisation réel.
3. une case à cocher intitulée "inverser" ci-dessus, éventuellement avec un "wtf est-ce
   merde?' lien vers la documentation.
4. ce serait une alternative beaucoup plus compliquée et pas clairement requise.
   "Je veux utiliser seulement quelques fonctions vimium dans gmail/twitter/other-app" est
   probablement quelque chose que beaucoup d'utilisateurs expérimentés voudraient (nous en avons déjà 2 ; et
   le total n'est pas énorme pour commencer).

Je ne m'oppose pas à la configuration de texte sophistiquée en soi, mais existe-t-il une fonctionnalité plus simple
demande qui couvre 90% des cas ? étant donné que je demande à quelqu'un que j'ai
jamais rencontré pour écrire du code pour moi gratuitement (pour autant qu'il le sache), je pense que c'est
m'incombe de vérifier.

Le mercredi 6 mai 2015 à 18h20, Matthew Ryan [email protected]
a écrit:

Quelques considérations :

• Cela désactive-t-il les clés avec des modificateurs ?
  
  
  
  • Si c'est le cas, il n'y aurait aucun moyen de les réactiver ; nous ne le faisons pas actuellement
    
    reconnaissez-les dans le champ des mots de passe (bien que #1368
    
    https://github.com/philc/vimium/pull/1368 pourrait être actualisé à
    
    répare ça).
  
  
  • Si ce n'est pas le cas, comment communiquons-nous cela de manière concise aux utilisateurs afin qu'ils soient
    
    pas pris par surprise ?
  
  
  • Si nous utilisons un + avant les clés exclusives, comment désactiver un mappage
    
    sur + ?
  
  
• Comment donner aux utilisateurs ce choix sur chaque règle (et leur permettre de voir
  quel choix ils ont déjà fait) clairement sans dépasser les limites
  espace dans la fenêtre contextuelle de l'icône ?
  
  
  
  • Peut-être unavec "désactiver" et "autoriser uniquement" comme options ?
    
    Serait-ce trop gros ?
  
  
  • Une configuration textuelle plus puissante comme celle de # 1188
    
    https://github.com/philc/vimium/issues/1188 être un
    
    alternative acceptable/bonne/meilleure ?
  
  

Les modifications réelles du code backend devraient être raisonnablement faciles, très peu
aurait besoin de changer là pour soutenir cela.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -99668372.

je suis heureux que la fonctionnalité pertinente ignore complètement les touches de mod

Mais est-ce la bonne chose à faire ? Personnellement, je me sentirais plus heureux d'atterrir #1368 (je vais envoyer un ping à Steve et voir si c'est une possibilité) et de rendre la fonctionnalité "seules les clés et les combinaisons dans le champ des mots de passe seront reconnues par Vimium", donc nous ne prenons personne par surprise.

une case à cocher intitulée "inverser" ci-dessus, éventuellement avec un "wtf est-ce que c'est de la merde ?" lien vers la documentation.

Pour la plupart, les gens ne liront pas la documentation, donc l'interface utilisateur doit être assez explicite. Je vais essayer avec une case à cocher "inverser" quand j'aurai le temps de le faire.

ce serait une alternative beaucoup plus compliquée et pas clairement requise.

D'accord. J'avais voulu plusieurs fois _changer_ certains mappages sur des pages où nos mappages et ceux de la page se chevauchent, et _les deux_ sont utiles - mais c'est probablement exagéré ici.

1. peut-être que ce n'est pas le cas, mais je ne vois pas pourquoi nous ne pouvons pas commencer par soutenir
   touches non-mod, puis ajoutez la prise en charge des touches mod plus tard.
2. nous pouvons désactiver la case à cocher et vous demander de l'activer via un paramètre,
   mais en général je ne suis pas d'accord. nous ne parlons pas de logiciel pour
   toutes les personnes. ceci est un programme pour les personnes contrariées par le fait que leur navigateur ne l'est pas
   assez comme vim. ils ont une tolérance supérieure à la moyenne pour la lecture
   Documentation.

Le jeudi 7 mai 2015 à 14h19, Matthew Ryan [email protected]
a écrit:

je suis heureux que la fonctionnalité pertinente ignore complètement les touches de mod

Mais est-ce la bonne chose à faire ? Personnellement, je me sentirais plus heureux d'atterrir

1368 https://github.com/philc/vimium/pull/1368 (je ping Steve et

voir si c'est une possibilité) et rendre la fonctionnalité "uniquement les touches et
les combinaisons dans le champ des clés de sécurité seront reconnues par Vimium", nous
ne surprenez personne.

une case à cocher intitulée "inverser" ci-dessus, éventuellement avec un "wtf est-ce que c'est de la merde ?"
lien vers la documentation.

Pour la plupart, les gens ne liront pas la documentation, donc l'interface utilisateur doit être
assez explicite. Je vais essayer avec une case à cocher "inverser" quand je reçois
rond pour faire ça.

ce serait une alternative beaucoup plus compliquée et pas clairement requise.

D'accord. Je l'avais voulu plusieurs fois pour _changer_ certains mappages sur les pages
où nos mappages et ceux de la page se chevauchent, et _les deux_ sont utiles - mais
c'est probablement exagéré ici.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100022074.

Ce n'est pas mon projet, et je ne suis pas un contributeur officiel, donc j'essaie juste de rester dans les objectifs de conception avec cette fonctionnalité. Mais cela pourrait être un bon candidat pour Vimium Labs (#1542) pendant que les détails sont élaborés.

Sur l'idée d'une bascule exclure/inclure... Cela (ré-)introduirait-il le problème selon lequel l'ordre de plusieurs règles de correspondance serait important?

Cela (ré-)introduirait-il le problème de l'importance de l'ordre des règles de correspondance multiples ?

Si nous les prenons comme "désactiver" vs "autoriser uniquement", alors nous pourrions appliquer toutes les règles "autoriser uniquement" en premier et soustraire les règles "désactivées" du résultat, de sorte que l'ordre ne devrait pas avoir d'importance.

Je ne connais pas la discussion précédente sur la question, mais pouvez-vous
pensez à une raison pour laquelle spécifier une règle de désactivation et une règle d'autorisation uniquement
pour la même URL n'est pas une erreur de l'utilisateur ? Je pense que la bonne chose à faire
serait d'avertir l'utilisateur qu'il avait fait quelque chose de bizarre, puis
Soit

une. ordonnez-leur de le réparer.
b. résolvez-le en ignorant la règle de désactivation.
c. résolvez-le comme le suggère Matthieu.

Je veux dire, je suppose que _peut-être_ un utilisateur veut ignorer W pour toutes les applications Google, mais
pas d'autres URL, et veut ensuite activer uniquement f sur gmail, ou
quelque chose, mais cela semble bizarre. Mais si nous autorisons l'étrange
possibilités, je souhaiterais peut-être désactiver W sur toutes les applications Google _sauf_ gmail,
et également activer f dans gmail.

Je suppose que ce ne serait pas trop de travail de développement supplémentaire pour rendre le
règle de résolution configurable (par rapport à l'analyse d'une spécification de clé
syntaxe ou un fichier de configuration plus compliqué), mais (b) semble toujours être le
meilleure solution pour moi. Quand je dis "autoriser uniquement", je veux probablement "autoriser
exactement."

Quelqu'un peut-il penser à un contre-exemple réaliste à ce qui précède? Peut-être "Je n'ai jamais
voulez exécuter certaines commandes sur des URL https" ou quelque chose comme ça ? Je ne sais pas.
only=me semble exactement le meilleur.

Le jeudi 7 mai 2015 à 21h08, Matthew Ryan [email protected]
a écrit:

Est-ce que cela (ré-)introduirait le problème que l'ordre des correspondances multiples
les règles auraient-elles de l'importance ?

Si nous les prenons comme "désactiver" vs "autoriser uniquement", alors nous pourrions appliquer tous les
"autoriser uniquement" les règles d'abord et soustraire les règles "désactivées" du résultat,
donc l'ordre ne devrait pas avoir d'importance.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100096596.

pouvez-vous penser à une raison pour laquelle spécifier une règle de désactivation et une règle d'autorisation uniquement pour la même URL n'est pas une erreur de l'utilisateur ?

Cela semble tout à fait raisonnable lorsqu'un utilisateur souhaite uniquement activer certaines clés pour un site entier et souhaite en outre supprimer certaines clés pour une page / partie spécifique du site. Par example:

autoriser uniquement :

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

désactiver:

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

Oh oui

Le vendredi 8 mai 2015 à 20h46, Matthew Ryan [email protected]
a écrit:

pouvez-vous penser à une raison pour laquelle spécifier une règle de désactivation et un
la règle d'autorisation uniquement pour la même URL n'est-elle pas une erreur de l'utilisateur ?

Cela semble tout à fait raisonnable lorsqu'un utilisateur ne souhaite activer que certaines touches pour un
l'ensemble du site, et souhaite en outre supprimer certaines clés pour une page / partie spécifique de
le site. Par example:

autoriser uniquement :

https?://votre.domaine.tld/* fJKjki

désactiver:

https?://votre.domaine.tld/a-particular-page jk

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100421213.

Un bon cas d'utilisation pour cela utilise JIRA. J'utilise la plupart des raccourcis pour JIRA (ce qui est beaucoup), mais j'aimerais toujours o pour rechercher un nouvel onglet et f pour suivre les liens. Je peux taper tout l'alphabet dans la case et ça va, mais une règle inverse serait plus simple :)

@smblott-github Pouvez-vous s'il vous plaît réviser cela ? J'ai également des besoins similaires, comme utiliser uniquement la touche "f" sur certains sites Web qui ont eux-mêmes de nombreux raccourcis clavier (JIRA, GMAIL, YOUTUBE, etc.).

Merci beaucoup!

Veuillez faire ceci, je voudrais utiliser Vimium uniquement pour la fonctionnalité "f", car je connais déjà de nombreux raccourcis chrome, c'est la seule chose dont j'ai besoin

@DamirCiganovic-Jankovic. Vous pouvez démapper les touches que vous n'utilisez jamais sur la page des options.

@smblott-github Je vois que cela a été fermé en raison d'un manque d'intérêt. Y a-t-il une chance de rouvrir cela si suffisamment d'intérêt est généré ? 😄

Pour ajouter ma propre histoire personnelle, j'ai utilisé fidèlement Vimium pendant des années jusqu'à il y a environ 2 ans, lorsque j'ai réalisé que _la plupart_ des sites que j'utilisais le plus souvent (gmail, github, reviewable) avaient trop de raccourcis contradictoires. J'ai donc fini par désactiver Vimium sur la plupart des sites que j'utilisais, alors j'ai simplement abandonné Vimium. Ce serait fantastique si je pouvais mettre en liste blanche quelques-uns des raccourcis Vimium les plus courants sur ces sites ( f serait en tête de liste, bien sûr).

_{(Futurs lecteurs, veuillez donner un coup de pouce au commentaire de haut niveau sur ce fil pour enregistrer votre intérêt !)}

Il semble que # 3272 signale également ce problème, et il existe de nombreux problèmes similaires. Y a-t-il quelqu'un intéressé par mon idée dans https://github.com/philc/vimium/issues/3272#issuecomment -475296695 ?

Je trouve que c'est une fonctionnalité essentielle et je pense que cela devrait être rouvert. Je suis content de parcourir le code mais je n'ai pas encore eu le temps. Donc, voici la solution de contournement que je vais essayer d'utiliser pour éviter tous les conflits sans avoir à désactiver complètement vimium partout.

Voici toutes les clés utilisées par vimium, à ma connaissance -
avec des espaces : ? hjklg G drsf F o O b BJK 0 $ ^ ytx XTW pma A ` iu U e E z HL v V
coupé : ?hjklgGdrsfFoObBJK0$^ytxXTWpmaA`iuUeEzHLvV

1. Accédez à votre éditeur de texte préféré (par exemple, Vscode)
2. coller la chaîne
3. recherchez et supprimez les clés que vous souhaitez activer dans Vimium.
4. Collez ce qui reste de la chaîne en tant que motif d'exclusion dans la fenêtre contextuelle Vimium