Genau das habe ich vor 3 Minuten gemacht. Ich bin die Liste der Verknüpfungen durchgegangen und habe die von Google Mail ausgeschlossenen Schlüssel auf jkhlgGzduryivVabceoOTbB[]m`nNHLKJtxXW<>? (Dies funktioniert möglicherweise nicht für Sie; ich habe bereits andere Konfigurationsänderungen vorgenommen.)

Ich bin mir jedoch nicht sicher, ob die von OP vorgeschlagene Lösung die beste ist. Eine einfachere Lösung, die die meisten Fälle abdeckt und keinen Haufen Parsing-Code erfordert, ist: Verwenden Sie einen Schalter, der das Feld von "Diese Tasten deaktivieren" auf "Nur diese Tasten aktivieren" ändert. Das ist eher die Art von Dingen, die Sie in einer Stunde erledigen könnten, wenn Sie die Vimium-Codebasis kennen würden.

Einige Überlegungen:

• Deaktiviert dies Tasten mit Modifikatoren?
  
  
  
  • Wenn ja, gäbe es keine Möglichkeit, sie wieder zu aktivieren; Wir erkennen diese derzeit nicht im Passkey-Feld (obwohl #1368 aktualisiert werden könnte, um das zu beheben).
  
  
  • Wenn nicht, wie teilen wir dies den Benutzern prägnant mit, damit sie nicht überrascht werden?
  
  
• Wenn wir ein + vor exklusiven Schlüsseln verwenden, wie deaktivieren Sie eine Zuordnung auf + ?
• Wie geben wir Benutzern diese Wahlmöglichkeit für jede Regel (und ermöglichen ihnen, zu sehen, welche Wahl sie bereits getroffen haben), ohne den begrenzten Platz im Symbol-Popup zu überschreiten?
  
  
  
  • Vielleicht ein <select> mit "deaktivieren" und "nur zulassen" als Optionen? Wäre das zu groß?
  
  
• Wäre eine leistungsfähigere textbasierte Konfiguration wie die in #1188 eine akzeptable/gute/bessere Alternative?

Die eigentlichen Backend-Code-Änderungen sollten relativ einfach sein, es müsste nur sehr wenig geändert werden, um dies zu unterstützen.

1. Ich habe die Mod-Keys tatsächlich komplett vergessen, also gut entdeckt. ich bin glücklich
   für die relevante Funktion, Mod-Keys vollständig zu ignorieren. Trend bei Web-Apps
   scheint sowieso in Richtung vim-artige Tastenkombinationen zu gehen, also brauchen wir das
   Zusammenstöße zu vermeiden.
2. Dies ist ein weiterer guter Grund, die +-Syntax nicht zu verwenden. oder zumindest nicht bis
   Ein Benutzer hat einen tatsächlichen Anwendungsfall.
3. ein Kontrollkästchen mit der Aufschrift „invert“ oben, möglicherweise mit einem „wtf is this
   Scheisse?' Link zur Dokumentation.
4. es wäre eine viel kompliziertere und nicht eindeutig erforderliche Alternative.
   „Ich möchte nur einige vimium-Funktionen in gmail/twitter/andere-app verwenden“ ist
   wahrscheinlich etwas, was viele Power-User wollen würden (wir haben bereits 2; und
   insgesamt ist anfangs nicht riesig).

Ich bin per se nicht gegen eine ausgefallene Textkonfiguration, aber gibt es eine einfachere Funktion?
Anfrage, die 90 % der Fälle abdeckt? vorausgesetzt, ich frage jemanden, den ich habe
nie getroffen, um Code für mich (soweit er weiß) kostenlos zu schreiben, ich denke, es ist
obliegt mir zu prüfen.

Am Mittwoch, 6. Mai 2015 um 18:20 Uhr, Matthew Ryan [email protected]
schrieb:

Einige Überlegungen:

• Deaktiviert dies Tasten mit Modifikatoren?
  
  
  
  • Wenn ja, gäbe es keine Möglichkeit, sie wieder zu aktivieren; wir derzeit nicht
    
    erkennen Sie diese im Passkey-Feld (obwohl #1368
    
    https://github.com/philc/vimium/pull/1368 könnte aktualisiert werden
    
    repariere das).
  
  
  • Wenn nicht, wie teilen wir dies den Benutzern prägnant mit, damit sie es sind
    
    nicht überrascht?
  
  
  • Wenn wir ein + vor exklusiven Schlüsseln verwenden, wie deaktivieren Sie eine Zuordnung
    
    auf +?
  
  
• Wie geben wir Benutzern diese Wahlmöglichkeit für jede Regel (und ermöglichen ihnen zu sehen
  welche Wahl sie bereits getroffen haben) deutlich, ohne das Begrenzte zu überschreiten
  Platz im Icon-Popup?
  
  
  
  • Vielleicht einmit "deaktivieren" und "nur zulassen" als Optionen?
    
    Wäre das zu groß?
  
  
  • Wäre eine leistungsfähigere textbasierte Konfiguration wie die in #1188
    
    https://github.com/philc/vimium/issues/1188 sein
    
    akzeptable/gute/bessere Alternative?
  
  

Die eigentlichen Änderungen am Backend-Code sollten relativ einfach sein, sehr wenig
müssten dort ändern, um dies zu unterstützen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/philc/vimium/issues/1560#issuecomment -99668372.

Ich bin froh, dass die relevante Funktion Mod-Keys vollständig ignoriert

Aber ist dies das Richtige? Persönlich würde ich mich glücklicher fühlen, #1368 zu landen (ich werde Steve anpingen und sehen, ob das eine Möglichkeit ist) und das Feature "nur die Schlüssel und Kombinationen im Passkey-Feld werden von Vimium erkannt" machen, also nehmen wir niemanden überraschend.

ein Kontrollkästchen mit der Aufschrift „invert“ oben, möglicherweise mit einem „wtf is this shit?“ Link zur Dokumentation.

Zum größten Teil werden die Leute die Dokumentation nicht lesen, also muss die Benutzeroberfläche ziemlich selbsterklärend sein. Ich werde es mit einem Kontrollkästchen "Invertieren" versuchen, wenn ich dazu komme.

es wäre eine viel kompliziertere und nicht eindeutig erforderliche Alternative.

Einverstanden. Ich wollte es ein paar Mal, um einige Zuordnungen auf Seiten zu _ändern_, auf denen sich unsere und die Zuordnungen der Seite überschneiden und _beide_ nützlich sind – aber hier ist es wahrscheinlich zu viel des Guten.

1. Vielleicht ist es das nicht, aber ich verstehe nicht, warum wir nicht mit der Unterstützung beginnen können
   Nicht-Mod-Schlüssel und fügen Sie später Unterstützung für Modkeys hinzu.
2. wir können das Kontrollkästchen deaktivieren und verlangen, dass Sie es über eine Einstellung aktivieren,
   aber generell stimme ich nicht zu. Wir reden nicht über Software für
   alle. Dies ist ein Programm für Leute, die sich darüber ärgern, dass ihr Browser es nicht ist
   genug wie vim. sie haben eine überdurchschnittliche Lesetoleranz
   Dokumentation.

Am Do, 7. Mai 2015 um 14:19 Uhr, Matthew Ryan [email protected]
schrieb:

Ich bin froh, dass die relevante Funktion Mod-Keys vollständig ignoriert

Aber ist dies das Richtige? Persönlich würde ich mich glücklicher fühlen, wenn ich lande

1368 https://github.com/philc/vimium/pull/1368 (Ich pinge Steve und

sehen, ob das eine Möglichkeit ist) und das Feature "nur die Tasten und
Kombinationen im Passkey-Feld werden von Vimium erkannt", so wir
überraschen Sie niemanden.

ein Kontrollkästchen mit der Aufschrift „invert“ oben, möglicherweise mit einem „wtf is this shit?“
Link zur Dokumentation.

Zum größten Teil werden die Leute die Dokumentation nicht lesen, also muss die Benutzeroberfläche es sein
ziemlich selbsterklärend. Ich werde es mit einem Kontrollkästchen "Invertieren" versuchen, wenn ich es bekomme
Runde dazu.

es wäre eine viel kompliziertere und nicht eindeutig erforderliche Alternative.

Einverstanden. Ich wollte es ein paar Mal, um einige Zuordnungen auf Seiten zu _ändern_
wo sich unsere und die Zuordnungen der Seite überschneiden und _beide_ nützlich sind — aber
hier ist es wohl übertrieben.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/philc/vimium/issues/1560#issuecomment -100022074.

Dies ist nicht mein Projekt und ich bin kein offizieller Mitwirkender, also versuche ich nur, mit dieser Funktion die Designziele einzuhalten. Aber das könnte ein guter Kandidat für Vimium Labs (#1542) sein, während die Details ausgearbeitet werden.

Zur Idee eines Ausschluss-/Einschluss-Umschalters ... Würde das (wieder) das Problem einführen, dass die Reihenfolge mehrerer übereinstimmender Regeln eine Rolle spielen würde?

Würde das (wieder) das Problem einführen, dass die Reihenfolge mehrerer übereinstimmender Regeln eine Rolle spielen würde?

Wenn wir sie als "deaktivieren" vs. "nur zulassen" betrachten, könnten wir zuerst alle "nur zulassen"-Regeln anwenden und die "deaktivierten" Regeln vom Ergebnis abziehen, sodass die Reihenfolge keine Rolle spielen sollte.

Ich bin mit der vorherigen Diskussion des Problems nicht vertraut, aber können Sie
Denken Sie an einen Grund, warum Sie eine Deaktivierungsregel und eine Nur-Zulassen-Regel angeben sollten
für die gleiche URL ist das kein Benutzerfehler? Ich würde denken, das Richtige zu tun
wäre, den Benutzer zu warnen, dass sie etwas Bizarres getan haben, und dann
entweder

A. befiehl ihnen, es zu reparieren.
B. Beheben Sie es, indem Sie die Deaktivierungsregel ignorieren.
C. lösen Sie es, wie Matthew vorschlägt.

Ich meine, ich nehme an, _vielleicht_ möchte ein Benutzer W für alle Google-Apps ignorieren, aber
nicht andere urls, und will dann zusätzlich nur f auf gmail aktivieren, oder
etwas, aber das scheint seltsam. Aber wenn wir das Seltsame zulassen
Möglichkeiten, ich möchte vielleicht W in allen Google-Apps außer_ Gmail deaktivieren,
und aktivieren Sie auch f in Google Mail.

Ich nehme an, es wäre nicht zu viel zusätzliche Entwicklungsarbeit, um das zu machen
Auflösungsregel konfigurierbar (im Vergleich zum Analysieren einer Schlüsselspezifikation
Syntax oder eine kompliziertere Konfigurationsdatei), aber (b) scheint immer noch so zu sein
beste lösung für mich. Wenn ich "nur zulassen" sage, möchte ich wahrscheinlich "erlauben".
exakt."

Fällt jemandem ein realistisches Gegenbeispiel zu obigem ein? Vielleicht „Ich habe nie
Willst du einen bestimmten Befehl auf https-URLs ausführen" oder so? Ich weiß nicht.
only=exakt scheint mir am besten.

Am Do, 7. Mai 2015 um 21:08 Uhr, Matthew Ryan [email protected]
schrieb:

Würde das (wieder) das Problem einführen, dass die Reihenfolge der Mehrfachübereinstimmung
Regeln spielen eine Rolle?

Wenn wir sie als "deaktivieren" vs. "nur zulassen" betrachten, könnten wir alle anwenden
"nur zulassen"-Regeln zuerst und subtrahieren Sie die "deaktivierten" Regeln vom Ergebnis,
Die Reihenfolge sollte also egal sein.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/philc/vimium/issues/1560#issuecomment -100096596.

Können Sie sich einen Grund vorstellen, warum das Angeben einer Deaktivierungsregel und einer Nur-Zulassen-Regel für dieselbe URL kein Benutzerfehler ist?

Scheint völlig vernünftig, wenn ein Benutzer nur einige Schlüssel für eine ganze Website aktiviert haben möchte und außerdem einige Schlüssel für eine bestimmte Seite / einen bestimmten Teil der Website löschen möchte. Beispielsweise:

nur zulassen:

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

deaktivieren:

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

Oh ja

Am Freitag, den 8. Mai 2015 um 20:46 Uhr, Matthew Ryan [email protected]
schrieb:

Können Sie sich einen Grund vorstellen, warum Sie eine Deaktivierungsregel und eine angeben
Allow-Only-Regel für dieselbe URL ist kein Benutzerfehler?

Scheint völlig vernünftig, wenn ein Benutzer nur einige Schlüssel für a aktiviert haben möchte
gesamte Website und möchte außerdem einige Schlüssel für eine bestimmte Seite / einen bestimmten Teil davon löschen
der Standort. Beispielsweise:

nur zulassen:

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

deaktivieren:

https?://ihre.domain.tld/eine-bestimmte-seite jk

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/philc/vimium/issues/1560#issuecomment -100421213.

Ein guter Anwendungsfall dafür ist die Verwendung von JIRA. Ich verwende die meisten Verknüpfungen für JIRA (was sehr viel ist), aber ich möchte immer noch o , um einen neuen Tab zu durchsuchen, und f , um Links zu folgen. Ich kann das ganze Alphabet in das Feld tippen und das ist ok, aber eine umgekehrte Regel wäre einfacher :)

@smblott-github Kannst du das bitte überarbeiten? Ich habe auch ähnliche Bedürfnisse, wie die Verwendung nur der "f"-Taste auf einigen Websites, die viele eigene Tastenkombinationen haben (JIRA, GMAIL, YOUTUBE usw.).

Vielen Dank!

Bitte tun Sie dies, ich möchte Vimium nur für die "f"-Funktionalität verwenden, da ich bereits viele Chrome-Shortcuts kenne, ist dies das einzige, was ich brauche

@DamirCiganovic-Jankovic. Sie können die Zuordnung der Tasten, die Sie nie verwenden, auf der Optionsseite aufheben.

@smblott-github Ich sehe, dass dies wegen mangelnden Interesses geschlossen wurde. Gibt es eine Chance, dies wieder zu eröffnen, wenn genügend Interesse geweckt wird? 😄

Um meine eigene persönliche Geschichte hinzuzufügen, habe ich Vimium jahrelang treu verwendet, bis ich vor etwa 2 Jahren feststellte, dass _die meisten_ der von mir am häufigsten verwendeten Websites (gmail, github, reviewable) zu viele widersprüchliche Verknüpfungen hatten. Am Ende hatte ich Vimium auf den meisten von mir verwendeten Websites deaktiviert, also habe ich Vimium einfach fallen gelassen. Es wäre fantastisch, wenn ich nur einige der häufigsten Vimium-Verknüpfungen auf diesen Seiten auf die weiße Liste setzen könnte ( f wäre natürlich ganz oben auf der Liste).

_{(Zukünftige Leser, geben Sie bitte einen Daumen nach oben für den Kommentar auf oberster Ebene in diesem Thread, um Ihr Interesse zu bekunden!)}

Scheint #3272 dieses Problem auch zu melden, und es gibt einige ähnliche Probleme. Gibt es jemanden, der sich für meine Idee in https://github.com/philc/vimium/issues/3272#issuecomment -475296695 interessiert?

Ich finde dies ein wesentliches Feature und denke, dass dies wiedereröffnet werden sollte. Ich bin froh, den Code durchzugehen, hatte aber noch keine Zeit. Also, hier ist die Problemumgehung, die ich versuchen werde, um alle Konflikte zu vermeiden, ohne vimium überall vollständig deaktivieren zu müssen.

Hier sind alle Schlüssel, die Vimium nach meinem besten Wissen verwendet -
mit Leerzeichen : ? hjklg G drsf F o O b BJK 0 $ ^ ytx XTW pma A ` iu U e E z HL v V
getrimmt : ?hjklgGdrsfFoObBJK0$^ytxXTWpmaA`iuUeEzHLvV

1. Gehen Sie zu Ihrem bevorzugten Texteditor (z. B. Vscode)
2. füge die Schnur ein
3. Suchen und entfernen Sie die Schlüssel, die Sie in Vimium aktivieren möchten.
4. Fügen Sie den Rest der Zeichenfolge als Ausschlussmuster in das Vimium-Popup ein