मैंने ठीक 3 मिनट पहले ऐसा ही किया था। मैंने शॉर्टकट की सूची देखी और gmail-बहिष्कृत कुंजियों को jkhlgGzduryivVabceoOTbB[]m`nNHLKJtxXW<> पर सेट किया? (यह आपके लिए काम नहीं कर सकता है; मैंने पहले से ही अन्य कॉन्फ़िगरेशन परिवर्तन किए हैं)

मुझे यकीन नहीं है कि ओपी का प्रस्तावित समाधान सबसे अच्छा है। एक आसान समाधान जो अधिकांश मामलों को कवर करेगा और पार्सिंग कोड की एक गुच्छा की आवश्यकता नहीं है: एक स्विच है जो 'इन कुंजियों को अक्षम करें' से 'केवल इन चाबियों को सक्षम' करने के लिए फ़ील्ड को बदलता है। यदि आप विमियम कोडबेस जानते हैं तो आप एक घंटे में इस तरह का और काम कर सकते हैं।

कुछ विचार:

• क्या यह संशोधक के साथ कुंजियाँ अक्षम करता है?
  
  
  
  • अगर ऐसा है, तो उन्हें फिर से सक्षम करने का कोई तरीका नहीं होगा; हम वर्तमान में इन्हें पासकी फ़ील्ड में नहीं पहचानते हैं (हालाँकि इसे ठीक करने के लिए #1368 को ताज़ा किया जा सकता है)।
  
  
  • यदि नहीं, तो हम उपयोगकर्ताओं को इसे संक्षिप्त रूप से कैसे संप्रेषित करते हैं ताकि वे आश्चर्यचकित न हों?
  
  
• यदि हम अनन्य कुंजियों से पहले + का उपयोग करते हैं, तो आप + पर मैपिंग को कैसे अक्षम करते हैं?
• हम प्रत्येक नियम पर उपयोगकर्ताओं को यह विकल्प कैसे देते हैं (और उन्हें यह देखने की अनुमति देते हैं कि उन्होंने पहले से कौन सा विकल्प बनाया है) आइकन पॉपअप में सीमित स्थान को ओवररन किए बिना स्पष्ट रूप से?
  
  
  
  • शायद एक <select> विकल्प के रूप में "अक्षम" और "केवल अनुमति दें" के साथ? क्या यह बहुत बड़ा होगा?
  
  
• क्या #1188 में से एक जैसा अधिक शक्तिशाली टेक्स्ट-आधारित कॉन्फ़िगरेशन स्वीकार्य/अच्छा/बेहतर विकल्प होगा?

वास्तविक बैकएंड कोड परिवर्तन यथोचित रूप से आसान होना चाहिए, इसका समर्थन करने के लिए बहुत कम परिवर्तन करने की आवश्यकता होगी।

1. मैं वास्तव में मॉड कीज़ के बारे में पूरी तरह से भूल गया था, इसलिए अच्छी तरह से देखा गया। में खुश हूँ
   प्रासंगिक सुविधा के लिए मॉड कुंजियों को पूरी तरह से अनदेखा करने के लिए। वेब ऐप्स पर रुझान
   वैसे भी विम-स्टाइल कीबाइंडिंग की ओर लगता है, इसलिए हमें इसकी आवश्यकता है
   झड़पों से बचने के लिए।
2. + -सिंटैक्स का उपयोग न करने का यह एक और बड़ा कारण है। या कम से कम तब तक नहीं
   उपयोगकर्ता के पास वास्तविक उपयोग-मामला होता है।
3. ऊपर 'इनवर्ट' लेबल वाला एक चेकबॉक्स, संभवत: 'wtf is this' के साथ
   मल?' दस्तावेज़ीकरण के लिए लिंक।
4. यह एक तरह से अधिक जटिल और स्पष्ट रूप से आवश्यक विकल्प नहीं होगा।
   "मैं gmail/twitter/other-app में केवल कुछ vimium फंक्शन का उपयोग करना चाहता हूँ" is
   शायद कुछ बहुत बिजली उपयोगकर्ता चाहते हैं (हमारे पास पहले से ही 2 हैं; तथा
   कुल शुरू करने के लिए बहुत बड़ा नहीं है)।

मैं फैंसी टेक्स्ट कॉन्फिगरेशन का विरोध नहीं करता, लेकिन क्या कोई आसान फीचर है?
अनुरोध जिसमें 90% मामले शामिल हैं? यह देखते हुए कि मैं किसी से पूछ रहा हूँ
मेरे लिए कोड लिखने के लिए कभी नहीं मिले (जहाँ तक वह जानता है) मुफ़्त, मुझे लगता है कि यह है
मुझ पर जाँच करने के लिए अवलंबी।

बुध, 6 मई, 2015 को शाम 6:20 बजे, मैथ्यू रयान सूचनाएं @github.com
लिखा था:

कुछ विचार:

• क्या यह संशोधक के साथ कुंजियाँ अक्षम करता है?
  
  
  
  • अगर ऐसा है, तो उन्हें फिर से सक्षम करने का कोई तरीका नहीं होगा; हम वर्तमान में नहीं
    
    इन्हें पासकी फ़ील्ड में पहचानें (हालाँकि #1368
    
    https://github.com/philc/vimium/pull/1368 को ताज़ा किया जा सकता है
    
    उसे फिक्स करें)।
  
  
  • यदि नहीं, तो हम इसे उपयोगकर्ताओं के लिए संक्षिप्त रूप से कैसे संप्रेषित करते हैं ताकि वे
    
    आश्चर्य से नहीं लिया?
  
  
  • यदि हम एक्सक्लूसिव कुंजियों से पहले + का उपयोग करते हैं, तो आप मैपिंग को कैसे अक्षम करते हैं
    
    पर +?
  
  
• हम उपयोगकर्ताओं को प्रत्येक नियम पर यह विकल्प कैसे देते हैं (और उन्हें देखने की अनुमति देते हैं
  उन्होंने क्या विकल्प पहले ही बना लिया है) स्पष्ट रूप से सीमित को खत्म किए बिना
  आइकन पॉपअप में जगह?
  
  
  
  • शायद एकविकल्प के रूप में "अक्षम करें" और "केवल अनुमति दें" के साथ?
    
    क्या यह बहुत बड़ा होगा?
  
  
  • क्या अधिक शक्तिशाली टेक्स्ट-आधारित कॉन्फिगरेशन #1188 की तरह होगा
    
    https://github.com/philc/vimium/issues/1188 एक हो
    
    स्वीकार्य/अच्छा/बेहतर विकल्प?
  
  

वास्तविक बैकएंड कोड परिवर्तन यथोचित रूप से आसान होना चाहिए, बहुत कम
इसका समर्थन करने के लिए वहां बदलने की आवश्यकता होगी।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/philc/vimium/issues/1560#issuecomment -99668372।

मैं मॉड कुंजियों को पूरी तरह से अनदेखा करने के लिए प्रासंगिक सुविधा के लिए खुश हूं

लेकिन क्या ऐसा करना सही है? व्यक्तिगत रूप से मुझे लैंडिंग #1368 में खुशी होगी (मैं स्टीव को पिंग करूंगा और देखूंगा कि क्या यह एक संभावना है) और "केवल पासकी फ़ील्ड में कुंजियों और संयोजनों को विमियम द्वारा पहचाना जाएगा", इसलिए हम किसी को नहीं लेते हैं आश्चर्यचकित करके।

ऊपर 'इनवर्ट' लेबल वाला एक चेकबॉक्स, संभवत: 'wtf is this shit?' के साथ दस्तावेज़ीकरण के लिए लिंक।

अधिकांश भाग के लिए लोग दस्तावेज़ीकरण नहीं पढ़ेंगे, इसलिए UI को बहुत आत्म-व्याख्यात्मक होना चाहिए। जब मैं ऐसा करने के लिए चक्कर लगाता हूं तो मैं इसे 'उलटा' चेकबॉक्स के साथ आज़माउंगा।

यह एक तरह से अधिक जटिल और स्पष्ट रूप से आवश्यक विकल्प नहीं होगा।

माना। मैं चाहता था कि इसे कुछ बार _बदलें_ उन पृष्ठों पर कुछ मैपिंग करें जहां हमारे और पेज के मैपिंग ओवरलैप होते हैं, और _दोनों_ उपयोगी होते हैं - लेकिन यह शायद यहां अधिक है।

1. शायद ऐसा नहीं है, लेकिन मुझे समझ नहीं आता कि हम समर्थन करके शुरुआत क्यों नहीं कर सकते
   गैर-मॉड कुंजी और फिर बाद में मोडकी के लिए समर्थन जोड़ें।
2. हम चेकबॉक्स को अक्षम कर सकते हैं और आपको सेटिंग के माध्यम से इसे सक्षम करने की आवश्यकता है,
   लेकिन सामान्य तौर पर मैं सहमत नहीं हूं। हम सॉफ्टवेयर के बारे में बात नहीं कर रहे हैं
   सब लोग। यह उन लोगों के लिए एक कार्यक्रम है जो अपने ब्राउज़र से परेशान नहीं हैं
   विम की तरह पर्याप्त। उनके पास पढ़ने के लिए औसत से अधिक सहनशीलता है
   दस्तावेज़ीकरण।

गुरु, 7 मई, 2015 दोपहर 2:19 बजे, मैथ्यू रयान सूचनाएं @github.com
लिखा था:

मैं मॉड कुंजियों को पूरी तरह से अनदेखा करने के लिए प्रासंगिक सुविधा के लिए खुश हूं

लेकिन क्या ऐसा करना सही है? व्यक्तिगत रूप से मुझे लैंडिंग में खुशी होगी

1368 https://github.com/philc/vimium/pull/1368 (मैं स्टीव को पिंग करूँगा और

देखें कि क्या यह एक संभावना है) और "केवल कुंजियाँ और" सुविधा बनाना
पासकी फ़ील्ड में संयोजनों को विमियम द्वारा पहचाना जाएगा", इसलिए हम
किसी को आश्चर्य से न लें।

ऊपर 'इनवर्ट' लेबल वाला एक चेकबॉक्स, संभवत: 'wtf is this shit?' के साथ
दस्तावेज़ीकरण के लिए लिंक।

अधिकांश भाग के लिए लोग दस्तावेज़ीकरण नहीं पढ़ेंगे, इसलिए UI होना चाहिए
सुंदर आत्म व्याख्यात्मक। जब मुझे मिलता है तो मैं इसे 'उलटा' चेकबॉक्स के साथ आज़माउंगा
ऐसा करने के लिए गोल।

यह एक तरह से अधिक जटिल और स्पष्ट रूप से आवश्यक विकल्प नहीं होगा।

माना। मैं इसे कुछ बार _change_ पृष्ठों पर कुछ मैपिंग के लिए चाहता था
जहां हमारे और पेज के मैपिंग ओवरलैप होते हैं, और _दोनों_ उपयोगी होते हैं - लेकिन
यह शायद यहाँ overkill है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/philc/vimium/issues/1560#issuecomment -100022074।

यह मेरा प्रोजेक्ट नहीं है, और मैं आधिकारिक योगदानकर्ता नहीं हूं, इसलिए मैं इस सुविधा के साथ केवल डिज़ाइन लक्ष्यों को बनाए रखने की कोशिश कर रहा हूं। लेकिन यह विमियम लैब्स (#1542) के लिए एक अच्छा उम्मीदवार हो सकता है, जबकि विवरण पर काम किया जाता है।

एक बहिष्कृत/टॉगल शामिल करने के विचार पर... क्या वह (पुनः-) इस मुद्दे को पेश करेगा कि एकाधिक मिलान नियमों का क्रम मायने रखता है?

क्या वह (पुनः-) इस मुद्दे को प्रस्तुत करेगा कि एकाधिक मिलान नियमों का क्रम मायने रखेगा?

अगर हम उन्हें "अक्षम" बनाम "केवल अनुमति दें" के रूप में लेते हैं, तो हम पहले सभी "केवल अनुमति दें" नियम लागू कर सकते हैं और परिणाम से "अक्षम" नियमों को घटा सकते हैं, इसलिए आदेश कोई फर्क नहीं पड़ता।

मैं इस मुद्दे की पिछली चर्चा से परिचित नहीं हूँ, लेकिन क्या आप कर सकते हैं
किसी भी कारण के बारे में सोचें कि एक अक्षम नियम और केवल-अनुमति वाले नियम को क्यों निर्दिष्ट किया गया है
उसी यूआरएल के लिए उपयोगकर्ता त्रुटि नहीं है? मुझे लगता है कि करना सही काम होगा
उपयोगकर्ता को चेतावनी देना होगा कि उन्होंने कुछ विचित्र किया है, और फिर
दोनों में से एक

ए। उन्हें ठीक करने का आदेश दें।
बी। अक्षम नियम को अनदेखा करके इसे हल करें।
सी। मैथ्यू के सुझाव के अनुसार इसे हल करें।

मेरा मतलब है, मुझे लगता है कि _maybe_ एक उपयोगकर्ता सभी Google ऐप्स के लिए W को अनदेखा करना चाहता है, लेकिन
अन्य यूआरएल नहीं, और फिर अतिरिक्त रूप से जीमेल पर केवल एफ को सक्षम करना चाहता है, या
कुछ, लेकिन यह अजीब लगता है। लेकिन अगर हम अजीबोगरीब के लिए अनुमति दे रहे हैं
संभावनाएं, मैं सभी Google ऐप्स _except_ gmail पर W को अक्षम करना चाह सकता हूं,
और gmail में f भी सक्षम करें।

मुझे लगता है कि इसे बनाने के लिए बहुत अधिक अतिरिक्त विकास कार्य नहीं होगा
संकल्प नियम विन्यास योग्य (कुंजी-विनिर्देश को पार्स करने की तुलना में
सिंटैक्स या अधिक जटिल कॉन्फ़िग फ़ाइल), लेकिन (बी) अभी भी ऐसा लगता है
मेरे लिए सबसे अच्छा समाधान। जब मैं कहता हूं "केवल अनुमति दें" मैं शायद "अनुमति" चाहता हूं
बिल्कुल।"

क्या कोई उपरोक्त के यथार्थवादी प्रतिवाद के बारे में सोच सकता है? शायद "मैं कभी नहीं
https urls पर कुछ कमांड चलाना चाहते हैं" या कुछ और? मुझे पता नहीं।
केवल = बिल्कुल मुझे सबसे अच्छा लगता है।

गुरु, 7 मई, 2015 को रात 9:08 बजे, मैथ्यू रयान सूचनाएं @github.com
लिखा था:

क्या वह (पुनः-) इस मुद्दे को पेश करेगा कि एकाधिक मिलान का आदेश
नियम मायने रखेंगे?

यदि हम उन्हें "अक्षम" बनाम "केवल अनुमति दें" के रूप में लेते हैं, तो हम सभी लागू कर सकते हैं
पहले "केवल अनुमति दें" नियम और परिणाम से "अक्षम" नियम घटाएं,
इसलिए आदेश मायने नहीं रखना चाहिए।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/philc/vimium/issues/1560#issuecomment -100096596।

क्या आप किसी कारण के बारे में सोच सकते हैं कि एक ही यूआरएल के लिए एक अक्षम नियम और केवल-अनुमति नियम निर्दिष्ट करना उपयोगकर्ता त्रुटि क्यों नहीं है?

पूरी तरह से उचित लगता है जब कोई उपयोगकर्ता पूरी साइट के लिए केवल कुछ कुंजी सक्षम करना चाहता है, और आगे साइट के किसी विशिष्ट पृष्ठ/भाग के लिए कुछ कुंजी छोड़ना चाहता है। उदाहरण के लिए:

केवल अनुमति दें:

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

अक्षम करना:

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

अरे हां

शुक्र, 8 मई, 2015 को रात 8:46 बजे, मैथ्यू रयान सूचनाएं @github.com
लिखा था:

क्या आप किसी अक्षम नियम को निर्दिष्ट करने का कोई कारण सोच सकते हैं और a
एक ही यूआरएल के लिए केवल-अनुमति नियम उपयोगकर्ता त्रुटि नहीं है?

पूरी तरह से उचित लगता है जब कोई उपयोगकर्ता केवल कुछ कुंजियों को सक्षम करना चाहता है a
पूरी साइट, और आगे एक विशिष्ट पृष्ठ/के भाग के लिए कुछ कुंजी छोड़ना चाहता है
जगह। उदाहरण के लिए:

केवल अनुमति दें:

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

अक्षम करना:

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/philc/vimium/issues/1560#issuecomment -100421213।

इसके लिए एक अच्छा उपयोग मामला JIRA का उपयोग कर रहा है। मैं जिरा (जो बहुत है) के लिए अधिकांश शॉर्टकट का उपयोग करता हूं, लेकिन मैं अभी भी एक नया टैब खोजना चाहता हूं, और लिंक का पालन करने के लिए एफ । मैं बॉक्स में पूरी वर्णमाला टाइप कर सकता हूं और यह ठीक है, लेकिन एक उल्टा नियम सरल होगा :)

@ smblott-github क्या आप कृपया इसे संशोधित कर सकते हैं? मेरी भी इसी तरह की ज़रूरतें हैं, जैसे कि कुछ वेबसाइटों पर केवल "f" कुंजी का उपयोग करना, जिनके पास अपने आप में कई मुख्य शॉर्टकट हैं (JIRA, GMAIL, YOUTUBE, आदि)।

बहुत - बहुत धन्यवाद!

कृपया ऐसा करें, मैं केवल "एफ" कार्यक्षमता के लिए विमियम का उपयोग करना चाहता हूं, क्योंकि मैं पहले से ही कई क्रोम शॉर्टकट जानता हूं, यह केवल एक चीज है जिसकी मुझे आवश्यकता है

@ दामिर सिगनोविक-जानकोविक। आप उन कुंजियों को अनमैप कर सकते हैं जिनका आप कभी भी विकल्प पृष्ठ पर उपयोग नहीं करते हैं।

@ smblott-github मैं देख रहा हूं कि यह रुचि की कमी के कारण बंद हो गया था। क्या पर्याप्त ब्याज उत्पन्न होने पर इसे फिर से खोलने का कोई मौका है? मैं

अपनी व्यक्तिगत कहानी जोड़ने के लिए, मैंने लगभग 2 साल पहले तक वर्षों तक विश्वासपूर्वक विमियम का उपयोग किया जब मुझे एहसास हुआ कि _अधिकतम_ जिन साइटों का मैंने सबसे अधिक बार उपयोग किया था (जीमेल, जीथब, समीक्षा योग्य) में बहुत सारे परस्पर विरोधी शॉर्टकट थे। इसलिए मैंने उपयोग की जाने वाली अधिकांश साइटों पर विमियम को अक्षम कर दिया, इसलिए मैंने अभी विमियम को छोड़ दिया। यह बहुत अच्छा होगा यदि मैं उन साइटों पर कुछ सबसे सामान्य विमियम शॉर्टकट्स को श्वेतसूची में डाल सकता हूं ( f निश्चित रूप से सूची में सबसे ऊपर होगा)।

_{(भविष्य के पाठक, कृपया अपनी रुचि दर्ज करने के लिए इस धागे पर शीर्ष-स्तरीय टिप्पणी पर एक अंगूठा दें!)}

लगता है #3272 भी इस समस्या की रिपोर्ट करता है, और कुछ इसी तरह के मुद्दे हैं। क्या https://github.com/philc/vimium/issues/3272#issuecomment -475296695 में मेरे विचार में कोई दिलचस्पी रखता है?

मुझे यह एक आवश्यक विशेषता लगती है और मुझे लगता है कि इसे फिर से खोलना चाहिए। मुझे कोड के माध्यम से जाने में खुशी हो रही है लेकिन अभी तक समय नहीं है। तो, यहाँ समाधान है जिसका उपयोग मैं पूरी तरह से विमियम को पूरी तरह से अक्षम न करते हुए सभी टकराव से बचने के लिए करने की कोशिश करूँगा।

मेरी सर्वोत्तम जानकारी के लिए यहाँ वे सभी कुंजियाँ दी गई हैं जिनका विमियम उपयोग करता है -
रिक्त स्थान के साथ : ? एचजेकेएलजी जी डीआरएसएफ एफ ओ ओ बी बीजेके 0 $ ^ वाईटीएक्स एक्सटीडब्ल्यू पीएमए ए ` आईयू यू ई ई जेड एचएल वी वी
छंटनी की गई : ?hjklgGdrsfFoObBJK0$^ytxXTWpmaA`iuUeEzHLvV

1. अपने पसंदीदा टेक्स्ट एडिटर पर जाएं (जैसे Vscode)
2. स्ट्रिंग पेस्ट करें
3. उन कुंजियों को खोजें और निकालें जिन्हें आप Vimium में सक्षम करना चाहते हैं।
4. स्ट्रिंग के बचे हुए हिस्से को विमियम पॉप अप में एक बहिष्कृत पैटर्न के रूप में पेस्ट करें