Vimium: Dalam mode temukan, sorot semua kecocokan di halaman, bukan hanya saat ini

Tidak saat ini. Saya pikir kami akan menerima tambalan jika tidak menyebabkan lag yang nyata.

Ini akan menjadi tugas yang cukup besar -- dengan asumsi kita masih menggunakan window.find() untuk melakukan pencarian, kita perlu memanggilnya berulang kali untuk memunculkan semua kecocokan dan kemudian menampilkan UI sorotan kita sendiri.

Jika kita akhirnya mengalami masalah itu, kita harus merobek estetika pertandingan Safari, IMO.

+1 untuk fitur ini.

+1

Vimium luar biasa! Ini adalah satu-satunya bagian yang hilang sejauh yang saya ketahui.

+1 untuk fitur ini. Saya sebenarnya ingin menyarankan ini sendiri, tetapi saya memiliki perasaan "Saya tidak bisa menjadi satu-satunya".

Yahh!

+1

+1

Jika/ketika ini diterapkan, alangkah baiknya juga melihat semua kecocokan ditandai secara visual di bilah gulir seperti yang dilakukan Chromium.

+1

Baru-baru ini mengetahui tentang vimium, tidak percaya saya belum menginstal ini lebih cepat.

+1

+1

+1

+1

+1
dan saya pikir ini akan menjadi fitur pembunuh lainnya

+1

tolong BERHENTI membalas dengan komentar +1 yang tidak berguna. itu tidak menambahkan apa pun ke diskusi, dan akan membuang banyak waktu orang karena mereka akan mendapatkan pemberitahuan tentang "kontribusi" Anda yang tidak berguna. gunakan fungsi "watch" untuk berlangganan tiket.

+1

+1, chrome default berperilaku menyoroti semua klik yang cocok. Jika menerapkannya lagi akan menjadi masalah kinerja, apakah mungkin untuk langsung memanggil pencarian chrome?

apakah mungkin untuk langsung memanggil pencarian chrome?

Tidak.

Untuk mengimplementasikan sesuatu seperti ini akan menginginkan sesuatu seperti (yang diperbarui) #1081 sehingga browser tidak menggantung pada setiap pencarian, yang meningkatkan beban pengembangan/pemeliharaan secara substansial.

Penutupan.
Populer seperti itu, kami tidak benar-benar memiliki cara untuk menerapkan ini.

(Vimium sebenarnya tidak melakukan penyorotan sama sekali, saat ini. Kami hanya memanggil window.find() .)

4 tahun...

+1 Ini benar-benar fitur hebat jika dapat diterapkan.

Saya melakukan beberapa penelitian. Ini sepertinya melakukannya http://stackoverflow.com/a/5887719/96100 (solusinya termasuk IE, sehingga dapat lebih disederhanakan dengan menghapus bagian IE)

Tapi saya pikir ada pertanyaan lebih lanjut - kapan dan bagaimana menghapus sorotan. Untuk kapan, saya pikir ketika memulai pencarian berikutnya atau ketika menjalankan sesuatu seperti :noh ; untuk caranya, saya berasumsi execCommand('undo') akan melakukannya.

Sangat menantikan fitur tersebut.

Ini diperlukan dan tidak yakin apakah itu seharusnya menjadi fitur khusus vimium, tetapi ekstensi mirip vim lainnya melakukan ini ( seperti surfingkeys misalnya ). Sudah hampir 5 tahun dan fitur ini belum ada. Apa yang sedang terjadi?

Saya melakukan beberapa penelitian. Ini sepertinya melakukannya http://stackoverflow.com/a/5887719/96100 (solusinya termasuk IE, sehingga dapat lebih disederhanakan dengan menghapus bagian IE)

Solusi ini tampaknya melibatkan modifikasi sebaris ke DOM halaman, yang membuat saya sangat tidak nyaman.

Apa yang sedang terjadi?

Ini sulit dilakukan dengan benar (atau, setidaknya, untuk kepuasan saya).

Implementasi yang lengkap harus

• temukan lintas elemen (yang tampaknya tidak dapat dilakukan oleh tombol selancar; lihat di sini dan di sini untuk kodenya)
  
  
  
  • misalnya. temukan dan sorot class SuppressPrintable (atau, lebih sulit lagi, sorot lass Supp ) di halaman ini
  
  
  • perhatikan bahwa baris yang kita pedulikan memiliki HTML <span class="pl-k">class</span> <span class="pl-en" style="background-color: transparent;">SuppressPrintable</span> <span class="pl-k">extends</span> <span class="pl-e">Mode</span>
  
  
  • misalnya. temukan dan sorot testtest di test<img src="#">test , seperti yang dilakukan find asli
  
  
  • temukan dan sorot testtest di test<input type="text">test (seperti Firefox) atau tidak (seperti Chrome).
  
  
• temukan dan sorot string yang disalin langsung dari halaman. Dua kasus berlaku:
  
  
  
  • induk memiliki white-space: normal atau nowrap . test string dirender sebagai test string , jadi kita perlu menemukannya. (surfingkeys tidak dapat melakukan ini, karena menggunakan node.data )
  
  
  • induk memiliki white-space: pre , pre-line atau pre-wrap . test string dirender sebagai test string , jadi kita perlu menemukannya
  
  
• temukan seluruh elemen yang mewakili spasi (mis. <br /> atau <p></p> ). (surfingkeys tidak bisa melakukan ini)
  
  
  
  • misalnya. Test<br />Test harus ditemukan dan disorot dengan mencari Test\nTest ( atau mungkin Test\r\nTest ? )
  
  
  • misalnya. <p>Test</p><p>Test</p> harus ditemukan dan disorot dengan mencari Test\n\nTest (atau Test\r\n\r\nTest )
  
  
• (opsional) temukan dan sorot kecocokan di <input> s, <textarea> s, <button> s, dll. Ini adalah kerumitan besar untuk dilakukan dengan benar.

Kita dapat menggunakan properti innerText untuk mendapatkan representasi teks dari halaman, yang memberi tahu kita sebagian besar kecocokan (kecuali -- terutama -- yang disebutkan dalam poin-poin terakhir), dan yang digunakan Vimium. Namun, untuk menyorot (atau bahkan membuat pilihan tanpa menggunakan window.find ), kita harus memetakan hasil pencarian teks (pada innerText ) kembali ke rentang di DOM.

Pendekatan yang saya sarankan (malas) untuk itu akan melibatkan semacam pencarian biner orang miskin, membuat Range s , dan menggunakan toString() untuk memetakan ke innerText . Saya sendiri tidak terlalu tertarik untuk menerapkan ini.

Sepertinya ini adalah fitur yang sangat diinginkan, tetapi mungkin semua persyaratan yang diambil bersama-sama terlalu besar untuk ditangani. Mungkin sekumpulan sub-langkah yang lebih kecil dapat membuat ini lebih mudah diakses.

+1

6 tahun kemudian, saya masih berharap memiliki fitur ini

• btw, plugin ini Chrome Regex Search menerapkan fungsi ini.
• Alangkah baiknya jika vimium juga dapat mendukung ini.

Ekstensi Chrome Regex Search menggunakan cara yang sangat berbahaya untuk menerapkan fitur penyorotan, dan dapat merusak beberapa halaman web normal karena dapat merusak kode JavaScript host dan menghapus beberapa tindakan mengklik.

Sepertinya bukan hanya saya yang mengalami masalah ini.

Saya melakukan beberapa penelitian. Ini sepertinya melakukannya http://stackoverflow.com/a/5887719/96100 (solusinya termasuk IE, sehingga dapat lebih disederhanakan dengan menghapus bagian IE)

Solusi ini tampaknya melibatkan modifikasi sebaris ke DOM halaman, yang membuat saya sangat tidak nyaman.

Apa yang sedang terjadi?

Ini sulit dilakukan dengan benar (atau, setidaknya, untuk kepuasan saya).

Implementasi yang lengkap harus

• temukan lintas elemen (yang tampaknya tidak dapat dilakukan oleh tombol selancar; lihat di sini dan di sini untuk kodenya)

  • misalnya. temukan dan sorot class SuppressPrintable (atau, lebih sulit lagi, sorot lass Supp ) di halaman ini
  • perhatikan bahwa baris yang kita pedulikan memiliki HTML <span class="pl-k">class</span> <span class="pl-en" style="background-color: transparent;">SuppressPrintable</span> <span class="pl-k">extends</span> <span class="pl-e">Mode</span>
  • misalnya. temukan dan sorot testtest di test<img src="#">test , seperti yang dilakukan find asli
  • temukan dan sorot testtest di test<input type="text">test (seperti Firefox) atau tidak (seperti Chrome).

• temukan dan sorot string yang disalin langsung dari halaman. Dua kasus berlaku:

  • induk memiliki white-space: normal atau nowrap . test string dirender sebagai test string , jadi kita perlu menemukannya. (surfingkeys tidak dapat melakukan ini, karena menggunakan node.data )
  • induk memiliki white-space: pre , pre-line atau pre-wrap . test string dirender sebagai test string , jadi kita perlu menemukannya

• temukan seluruh elemen yang mewakili spasi (mis. <br /> atau <p></p> ). (surfingkeys tidak bisa melakukan ini)

  • misalnya. Test<br />Test harus ditemukan dan disorot dengan mencari Test\nTest ( atau mungkin Test\r\nTest ? )
  • misalnya. <p>Test</p><p>Test</p> harus ditemukan dan disorot dengan mencari Test\n\nTest (atau Test\r\n\r\nTest )
• (opsional) temukan dan sorot kecocokan di <input> s, <textarea> s, <button> s, dll. Ini adalah kerumitan besar untuk dilakukan dengan benar.

Kita dapat menggunakan properti innerText untuk mendapatkan representasi teks dari halaman, yang memberi tahu kita sebagian besar kecocokan (kecuali -- terutama -- yang disebutkan dalam poin-poin terakhir), dan yang digunakan Vimium. Namun, untuk menyorot (atau bahkan membuat pilihan tanpa menggunakan window.find ), kita harus memetakan hasil pencarian teks (pada innerText ) kembali ke rentang di DOM.

Pendekatan yang saya sarankan (malas) untuk itu akan melibatkan semacam pencarian biner orang miskin, membuat Range s , dan menggunakan toString() untuk memetakan ke innerText . Saya sendiri tidak terlalu tertarik untuk menerapkan ini.

Saya juga melakukan riset tentang window.find(). Ini hanya menyoroti hasil saat ini di web, tidak menyoroti semua hasil. Mungkin memanggil metode ini berkali-kali? Saya pikir itu bukan ide yang baik untuk masalah ini.

bagaimana dengan rutinitas ini?

dalam mode find, sebelum pengguna menekan tombol enter, panggil window.find() hanya sekali untuk setiap input yang diperbarui.

setelah digunakan tekan tombol enter, panggil window.find() untuk menampilkan semua kejadian.
[ mungkin, untuk mengingat posisi hasil pencarian tepat sebelum masuk ]

window.find() selalu menyorot area yang dipilih "saat ini", sementara tidak ada metode yang sempurna untuk mensimulasikan blok warna latar belakang (misalnya, jika sebuah garis memiliki warna/gambar latar belakangnya, maka warna latar belakang yang disimulasikan tidak akan terlihat).

window.find() selalu menyorot area yang dipilih "saat ini", sementara tidak ada metode yang sempurna untuk mensimulasikan blok warna latar belakang (misalnya, jika sebuah garis memiliki warna/gambar latar belakangnya, maka warna latar belakang yang disimulasikan tidak akan terlihat).

Hai, Biarkan saya lebih jelas tentang rutinitas saya.

Ketik pengguna a , panggil window.find hingga mengembalikan NULL. kumpulkan semua pertandingan
Ketik pengguna ab , panggil window.find hingga mengembalikan NULL. kumpulkan semua pertandingan, jatuhkan sebelumnya
Saat menggunakan hit enter , sebenarnya gunakan array hasil pencarian.

@Piping window.find() selalu menghapus semua area penyorotan lama dan kemudian hanya menyorot satu yang baru, jadi sebenarnya tidak ada API JavaScript untuk menyorot daftar area.

Penafian: Saya tidak lagi mengerjakan ekstensi browser dalam bentuk apa pun, jadi pengetahuan saya kemungkinan sudah ketinggalan zaman.

Ketik pengguna a , panggil window.find hingga mengembalikan NULL . kumpulkan semua pertandingan
Ketik pengguna ab , panggil window.find hingga mengembalikan NULL . kumpulkan semua pertandingan, jatuhkan sebelumnya

window.find mengerikan dan harus dihindari bila memungkinkan

• Ini berjalan di utas utama, sehingga memblokir input pengguna
• Ini memiliki efek UI, sehingga juga memaksa rendering dan selanjutnya memblokir input pengguna
• Ini berbasis seleksi, jadi CSS yang memblokir teks agar tidak dipilih dapat memiliki berbagai perilaku aneh, tergantung pada browser pilihan Anda
• Itu tidak (atau setidaknya, tidak digunakan untuk) membungkus FF
• Itu di luar spesifikasi dan secara resmi tidak digunakan lagi, tanpa niat untuk membakukan perilaku antar browser
• Mengambil data seleksi dengan cara ini jauh lebih mahal daripada menanyakan DOM secara langsung.
  
  
  
  • Seperti yang dikatakan Dahan dengan benar, penyorotan yang sebenarnya selalu dibuang, jadi kami harus mengumpulkan ini untuk menyorot lebih dari 1 kecocokan
  
  
  • <input> / <textarea> s sulit untuk mengeluarkan data ini dengan baik, bahkan sebelum kita harus khawatir tentang masalah non-sepele dalam menyorot teks di dalamnya.
  
  

Ketika saya menjadi kontributor, kami berjuang untuk menghitung jumlah hasil pencarian karena betapa lambatnya itu di halaman besar. Menggunakan window.find adalah tentang urutan besarnya lebih lambat, dan tidak bekerja sama sekali dengan pencarian ekspresi reguler. Saya sangat menyarankan agar tidak menggunakannya untuk lebih dari sekadar menjalankan satu pencarian, dan bahkan itu harus menjadi pilihan terakhir.

@gdh1995 Saya tidak bermaksud menggunakan windows.find() seperti yang Anda katakan. Itu hanyalah teks find saja.
@mrmr1993 Saya mengerti fitur ini membutuhkan lebih banyak daya komputasi atau upaya manusia. Tetapi setidaknya pengguna harus memiliki pilihan [opsi dalam konfigurasi] untuk melakukan ini menggunakan vimium meskipun lambat untuk perspektif pengguna. Bagaimanapun, agak menjengkelkan bahwa terkadang Ctrl-F digunakan dan terkadang / digunakan dan / tidak berfungsi seperti yang diharapkan ( bahkan di vim ).

Apakah ada hal lain selain alasan filosofis mengapa ekstensi tidak dapat mengizinkan jenis fitur ini begitu saja, dan memasukkannya ke dalam bagian "eksperimental" dari pengaturan ekstensi, dengan peringatan yang tepat untuk mencatat bahwa itu dapat merusak beberapa halaman? Ini sepertinya permintaan yang cukup populer sehingga masuk akal untuk menambahkannya di sana. Saya cukup senang dengan ekstensi " Highlighter Pilihan " misalnya, terlepas dari kenyataan bahwa itu mungkin merusak halaman, hanya karena utilitasnya lebih besar daripada risikonya; Saya pikir hal yang sama berlaku di sini.

+1 di sekitar sini. :)

Saya menggemakan sentimen macintaco.

Saya menggunakan pencarian vimium sebagai pengganti alat find sehingga saya dapat menjaga pintasan keyboard tetap seragam di berbagai pemasangan (selalu gunakan / untuk menemukan barang).

+1

Firefox memiliki browser.find.find dan browser.find.highlightResults . Tampaknya tidak mendukung regex, tetapi sebaliknya sepertinya persis seperti yang dibutuhkan masalah ini.

Saya hanya ingin mencatat bahwa SurfingKeys menyoroti kecocokan pada halaman melalui fungsi pencariannya. Saya tidak tahu bagaimana mereka melakukannya (tampaknya semacam overlay) tetapi "cukup baik" sampai-sampai saya menggunakan ekstensi itu sekarang. YMMV.

+1 - berharap setidaknya ada solusi untuk ini.

8 tahun... :)

Baru-baru ini saya mendapat ide lain: tidak perlu menggambar warna latar belakang yang menonjol, dan kita dapat menggunakan masking rect sebagai gantinya. Oleh karena itu saya telah menerapkan versi sederhana di Vimium saya yang disesuaikan, Vimium C , dan mendukung Ctrl+J/K untuk menemukan berikutnya/sebelumnya dan Ctrl+Shift+J/K untuk mem-flash rect pada semua kecocokan di area yang terlihat saat ini.