Saya baru saja melakukan ini 3 menit yang lalu. Saya melihat daftar pintasan dan menyetel kunci yang dikecualikan gmail ke jkhlgGzduryivVabceoOTbB[]m`nNHLKJtxXW<>? (ini mungkin tidak berhasil untuk Anda; saya sudah membuat perubahan konfigurasi lainnya)

Saya tidak yakin solusi yang diusulkan OP adalah yang terbaik. Solusi sederhana yang akan mencakup sebagian besar kasus dan tidak memerlukan banyak kode penguraian adalah: miliki sakelar yang mengubah bidang dari 'nonaktifkan kunci ini' menjadi 'hanya aktifkan kunci ini'. Itu lebih merupakan hal yang dapat Anda lakukan dalam satu jam jika Anda mengetahui basis kode vimium.

Beberapa pertimbangan:

• Apakah ini menonaktifkan kunci dengan pengubah?
  
  
  
  • Jika demikian, tidak ada cara untuk mengaktifkannya kembali; saat ini kami tidak mengenali ini di bidang kunci sandi (walaupun #1368 dapat disegarkan untuk memperbaikinya).
  
  
  • Jika tidak, bagaimana kami mengomunikasikannya secara singkat kepada pengguna sehingga mereka tidak terkejut?
  
  
• Jika kita menggunakan + sebelum kunci eksklusif, bagaimana Anda menonaktifkan pemetaan pada + ?
• Bagaimana kami memberi pengguna pilihan ini pada setiap aturan (dan memungkinkan mereka untuk melihat pilihan apa yang telah mereka buat) dengan jelas tanpa melampaui ruang terbatas di ikon popup?
  
  
  
  • Mungkin <select> dengan "nonaktifkan" dan "hanya izinkan" sebagai opsi? Apakah itu terlalu besar?
  
  
• Apakah konfigurasi berbasis teks yang lebih kuat seperti yang ada di #1188 menjadi alternatif yang dapat diterima/baik/lebih baik?

Perubahan kode backend yang sebenarnya seharusnya cukup mudah, sangat sedikit yang perlu diubah di sana untuk mendukung ini.

1. saya sebenarnya benar-benar lupa tentang kunci mod, sangat terlihat. saya senang
   untuk fitur yang relevan untuk mengabaikan kunci mod sepenuhnya. tren di aplikasi web
   tampaknya menuju ikatan kunci gaya vim, jadi di situlah kita perlu
   untuk menghindari bentrokan.
2. ini adalah alasan bagus lainnya untuk tidak menggunakan +-sintaks. atau setidaknya tidak sampai
   pengguna memiliki kasus penggunaan yang sebenarnya.
3. satu kotak centang berlabel 'invert' di atas, mungkin dengan 'wtf is this
   kotoran?' tautan ke dokumentasi.
4. itu akan menjadi alternatif yang jauh lebih rumit dan tidak diperlukan secara jelas.
   "Saya hanya ingin menggunakan beberapa fungsi vimium di gmail/twitter/aplikasi lain" adalah
   mungkin sesuatu yang diinginkan oleh banyak pengguna listrik (kami sudah memiliki 2; dan
   total tidak besar untuk memulai).

Saya tidak menentang konfigurasi teks mewah, tetapi apakah ada fitur yang lebih sederhana?
permintaan yang mencakup 90% kasus? mengingat bahwa saya bertanya kepada seseorang yang saya miliki
tidak pernah bertemu untuk menulis kode untuk saya (sejauh yang dia tahu) gratis, saya merasa itu
kewajiban saya untuk memeriksa.

Pada hari Rabu, 6 Mei 2015 jam 18:20, Matthew [email protected]
menulis:

Beberapa pertimbangan:

• Apakah ini menonaktifkan kunci dengan pengubah?
  
  
  
  • Jika demikian, tidak ada cara untuk mengaktifkannya kembali; kami saat ini tidak
    
    kenali ini di bidang kunci sandi (walaupun #1368
    
    https://github.com/philc/vimium/pull/1368 dapat disegarkan ke
    
    Perbaiki itu).
  
  
  • Jika tidak, bagaimana kami mengomunikasikan hal ini secara singkat kepada pengguna agar mereka
    
    tidak terkejut?
  
  
  • Jika kami menggunakan + sebelum kunci eksklusif, bagaimana Anda menonaktifkan pemetaan
    
    pada +?
  
  
• Bagaimana kami memberi pengguna pilihan ini pada setiap aturan (dan memungkinkan mereka untuk melihat
  pilihan apa yang telah mereka buat) dengan jelas tanpa melampaui batas
  ruang di popup ikon?
  
  
  
  • Mungkindengan "nonaktifkan" dan "izinkan saja" sebagai opsi?
    
    Apakah itu terlalu besar?
  
  
  • Apakah konfigurasi berbasis teks yang lebih kuat seperti yang ada di # 1188
    
    https://github.com/philc/vimium/issues/1188 jadilah
    
    alternatif yang dapat diterima/baik/lebih baik?
  
  

Perubahan kode backend yang sebenarnya seharusnya cukup mudah, sangat sedikit
perlu berubah di sana untuk mendukung ini.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -99668372.

saya senang dengan fitur yang relevan untuk mengabaikan kunci mod sepenuhnya

Tapi apakah ini hal yang benar untuk dilakukan? Secara pribadi saya akan merasa lebih bahagia mendarat #1368 (Saya akan ping Steve dan melihat apakah itu kemungkinan) dan membuat fitur "hanya tombol dan kombinasi di bidang kunci sandi yang akan dikenali oleh Vimium", jadi kami tidak mengambil siapa pun dengan kejutan.

satu kotak centang berlabel 'invert' di atas, mungkin dengan 'wtf is this shit?' tautan ke dokumentasi.

Untuk sebagian besar orang tidak akan membaca dokumentasi, jadi UI harus cukup jelas. Saya akan mencobanya dengan kotak centang 'balik' ketika saya melakukan ini.

itu akan menjadi alternatif yang jauh lebih rumit dan tidak diperlukan secara jelas.

Sepakat. Saya ingin beberapa kali _mengubah_ beberapa pemetaan pada halaman di mana pemetaan kami dan halaman tumpang tindih, dan _keduanya_ berguna — tetapi mungkin berlebihan di sini.

1. mungkin tidak, tetapi saya tidak mengerti mengapa kami tidak dapat memulai dengan mendukung
   kunci non-mod dan kemudian tambahkan dukungan untuk modkeys nanti.
2. kami dapat menonaktifkan kotak centang dan meminta Anda untuk mengaktifkannya melalui pengaturan,
   tapi secara umum saya tidak setuju. kita tidak berbicara tentang perangkat lunak untuk
   setiap orang. ini adalah program untuk orang-orang yang kecewa dengan browser mereka
   cukup seperti vim. mereka memiliki toleransi membaca yang lebih tinggi dari rata-rata
   dokumentasi.

Pada Kam, 7 Mei 2015 pukul 14.19, Matthew Ryan [email protected]
menulis:

saya senang dengan fitur yang relevan untuk mengabaikan kunci mod sepenuhnya

Tapi apakah ini hal yang benar untuk dilakukan? Secara pribadi saya akan merasa lebih bahagia saat mendarat

1368 https://github.com/philc/vimium/pull/1368 (Saya akan melakukan ping ke Steve dan

lihat apakah itu kemungkinan) dan buat fitur "hanya tombol dan
kombinasi di bidang kunci sandi akan dikenali oleh Vimium", jadi kami
jangan mengejutkan siapa pun.

satu kotak centang berlabel 'invert' di atas, mungkin dengan 'wtf is this shit?'
tautan ke dokumentasi.

Sebagian besar orang tidak akan membaca dokumentasi, jadi UI harus
cukup jelas. Saya akan mencobanya dengan kotak centang 'balik' ketika saya mendapatkannya
bulat untuk melakukan ini.

itu akan menjadi alternatif yang jauh lebih rumit dan tidak diperlukan secara jelas.

Sepakat. Saya ingin beberapa kali _mengubah_ beberapa pemetaan di halaman
di mana pemetaan kami dan halaman tumpang tindih, dan _both_ berguna — tetapi
itu mungkin berlebihan di sini.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100022074.

Ini bukan proyek saya, dan saya bukan kontributor resmi, jadi saya hanya mencoba untuk tetap dalam tujuan desain dengan fitur ini. Tapi ini mungkin kandidat yang baik untuk Vimium Labs (#1542) sementara detailnya dikerjakan.

Tentang gagasan sakelar pengecualian/sertakan... Apakah itu (kembali) menimbulkan masalah bahwa pengurutan beberapa aturan pencocokan akan menjadi masalah?

Apakah itu (kembali) akan menimbulkan masalah bahwa pengurutan beberapa aturan pencocokan akan menjadi masalah?

Jika kita menganggapnya sebagai "nonaktifkan" vs "hanya izinkan", maka kita dapat menerapkan semua aturan "hanya izinkan" terlebih dahulu dan mengurangi aturan "nonaktif" dari hasilnya, jadi urutannya tidak menjadi masalah.

Saya tidak terbiasa dengan diskusi masalah sebelumnya, tetapi bisakah Anda
pikirkan alasan apa pun mengapa menentukan aturan penonaktifan dan aturan hanya izinkan
untuk url yang sama bukan kesalahan pengguna? Saya akan memikirkan hal yang benar untuk dilakukan
akan memperingatkan pengguna bahwa mereka telah melakukan sesuatu yang aneh, dan kemudian—
salah satu

sebuah. memerintahkan mereka untuk memperbaikinya.
B. selesaikan dengan mengabaikan aturan nonaktifkan.
C. menyelesaikannya seperti yang disarankan Matthew.

Maksud saya, saya kira _mungkin_ pengguna ingin mengabaikan W untuk semua aplikasi Google, tapi
bukan url lain, dan kemudian hanya ingin mengaktifkan f di gmail, atau
sesuatu, tapi ini tampak aneh. Tetapi jika kita membiarkan yang aneh
kemungkinan, saya mungkin ingin menonaktifkan W di semua aplikasi google _kecuali_ gmail,
dan juga aktifkan f di gmail.

Saya kira tidak akan terlalu banyak pekerjaan pengembangan tambahan untuk membuat
aturan resolusi dapat dikonfigurasi (dibandingkan dengan menguraikan spesifikasi kunci
sintaks atau file konfigurasi yang lebih rumit), Tetapi (b) masih tampak seperti
solusi terbaik untuk saya. Ketika saya mengatakan "izinkan saja" saya mungkin ingin "izinkan
tepat."

Adakah yang bisa memikirkan contoh tandingan realistis di atas? Mungkin "Saya tidak pernah"
ingin menjalankan perintah tertentu di url https" atau apa? Entahlah.
only=persis sepertinya yang terbaik bagi saya.

Pada Kam, 7 Mei 2015 jam 21:08, Matthew [email protected]
menulis:

Apakah itu (kembali) memperkenalkan masalah bahwa pemesanan beberapa pencocokan?
aturan akan penting?

Jika kita menganggapnya sebagai "nonaktifkan" vs "izinkan saja", maka kita dapat menerapkan semua
aturan "hanya izinkan" terlebih dahulu dan kurangi aturan "nonaktif" dari hasilnya,
jadi urutannya tidak masalah.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100096596.

dapatkah Anda memikirkan alasan mengapa menetapkan aturan nonaktifkan dan aturan hanya izinkan untuk url yang sama bukanlah kesalahan pengguna?

Tampaknya sepenuhnya masuk akal ketika pengguna hanya ingin beberapa kunci diaktifkan untuk seluruh situs, dan selanjutnya ingin menjatuhkan beberapa kunci untuk halaman/bagian tertentu dari situs. Sebagai contoh:

izinkan saja:

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

cacat:

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

Oh ya

Pada Jumat, 8 Mei 2015 jam 20:46, Matthew [email protected]
menulis:

dapatkah Anda memikirkan alasan apa pun mengapa menentukan aturan penonaktifan dan
aturan izinkan-saja untuk url yang sama bukan kesalahan pengguna?

Tampaknya sepenuhnya masuk akal ketika pengguna hanya ingin beberapa kunci diaktifkan untuk a
seluruh situs, dan selanjutnya ingin menjatuhkan beberapa kunci untuk halaman/bagian tertentu dari
situs. Sebagai contoh:

izinkan saja:

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

cacat:

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

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/philc/vimium/issues/1560#issuecomment -100421213.

Kasus penggunaan yang baik untuk ini adalah menggunakan JIRA. Saya menggunakan sebagian besar pintasan untuk JIRA (yang banyak), tetapi saya masih ingin o mencari tab baru, dan f mengikuti tautan. Saya dapat mengetik seluruh alfabet di dalam kotak dan tidak apa-apa, tetapi aturan sebaliknya akan lebih sederhana :)

@smblott-github Bisakah Anda merevisi ini? Saya juga memiliki kebutuhan serupa, seperti hanya menggunakan tombol "f" di beberapa situs web yang memiliki banyak pintasan tombol sendiri (JIRA, GMAIL, YOUTUBE, dll.).

Terima kasih banyak!

Tolong lakukan ini, saya ingin menggunakan Vimium hanya untuk fungsionalitas "f", karena saya sudah tahu banyak pintasan chrome, ini adalah satu-satunya hal yang saya butuhkan

@DamirCiganovic-Jankovic. Anda dapat menghapus peta kunci yang tidak pernah Anda gunakan di halaman opsi.

@smblott-github Saya melihat ini ditutup karena kurangnya minat. Apakah ada peluang untuk membuka kembali ini jika cukup banyak minat yang dihasilkan? 😄.

Untuk menambahkan kisah pribadi saya, saya menggunakan Vimium dengan setia selama bertahun-tahun hingga sekitar 2 tahun yang lalu ketika saya menyadari bahwa _sebagian besar_ situs yang paling sering saya gunakan (gmail, github, dapat ditinjau) memiliki terlalu banyak pintasan yang bentrok. Jadi saya akhirnya menonaktifkan Vimium di sebagian besar situs yang saya gunakan, jadi saya membuang Vimium. Akan luar biasa jika saya dapat memasukkan beberapa pintasan Vimium yang paling umum di situs tersebut ke daftar putih ( f tentu saja akan menjadi yang teratas dalam daftar).

_{(Pembaca masa depan, tolong beri jempol pada komentar tingkat atas di utas ini untuk mendaftarkan minat Anda!)}

Sepertinya #3272 juga melaporkan masalah ini, dan ada beberapa masalah serupa. Apakah ada seseorang yang tertarik dengan ide saya di https://github.com/philc/vimium/issues/3272#issuecomment -475296695?

Saya menemukan ini fitur penting dan berpikir ini harus dibuka kembali. Saya senang membaca kode tetapi belum punya waktu. Jadi, inilah solusi yang akan saya coba gunakan untuk menghindari semua bentrokan tanpa harus menonaktifkan vimium sepenuhnya di semua tempat.

Berikut adalah semua kunci yang digunakan vimium, sepengetahuan saya -
dengan spasi : ? hjklg G drsf F o O b BJK 0 $ ^ ytx XTW pma A ` iu U e E z HL v V
dipangkas : ?hjklgGdrsfFoObBJK0$^ytxXTWpmaA`iuUeEzHLvV

1. Buka editor teks favorit Anda (mis. Vscode)
2. rekatkan talinya
3. cari dan hapus kunci yang ingin Anda aktifkan di Vimium.
4. Rekatkan sisa string sebagai pola pengecualian di pop up Vimium