Seberapa jauh mimpi dari pencarian "file sempurna"

Apakah Anda sering menjalankan pencarian pada file teks? Saya - setiap hari selama lebih dari 25 tahun.

Tugas saya sangat berbeda dalam kompleksitas dan ruang lingkup.

Pertama, sebagai seorang programmer, tentu saja, saya perlu mencari dalam kode. Tugas-tugas ini sederhana (set folder dan file kecil) dan cepat (hasilnya muncul segera).

Kedua, sebagai operator, saya harus mencari ratusan (kadang-kadang ribuan) folder di antara ribuan (kadang-kadang ratusan ribu) file. Ini adalah tugas yang sulit baik dari segi volume hasil dan dalam hal waktu mereka. Biasanya, hasil pencarian tersebut masih membutuhkan pemrosesan manual atau perangkat lunak lebih lanjut.

Semua pekerjaan dilakukan pada Windows.

Saya akan memberi tahu Anda di mana keinginan membuat saya memiliki alat yang cocok untuk tugas-tugas tersebut.

Pada awalnya adalah TextPad

Selama lebih dari 10 tahun, TextPad telah menjadi alat utama saya yang mudah .
Kemudian (sebelum dan sedikit setelah tahun 2000) ia melakukan pekerjaan yang sangat baik.

Pencarian file tampak seperti ini ( TextPad , 2004)

Gulungan dan perbandingan

Keterbatasan TextPad dan pembekuannya menyebabkan uji coba konstan editor lain.
Sekarang Anda tidak dapat mengingat semua yang sudah dicoba, tetapi di antaranya adalah:

• MS Visual Studio . Monster berat.
• Gerhana Juga monster.

• IntelliJ IDEA . Menawan Dilayani dan berfungsi sebagai penyedia contoh bagaimana Anda dapat melakukannya dengan nyaman .

  
  
  Tayangan

  IDEA lama itu sudah hilang. Sebagai perbandingan, implementasi saat ini di PyCharm , 2017.1.3
  
  (+) Jumlah pengaturan dan mode yang tak terbayangkan.
  (+) Kemandirian dialog: hasil, kode sumber, dan statistik pencarian terlihat.
  (-) Tidak ada batasan pada kedalaman pencarian di folder - baik satu atau sekaligus.
  (-) Tidak (saya tidak tahu caranya) mencari di beberapa folder.
  (-) Tidak (saya tidak tahu caranya) menampilkan hasil dalam format teks.

  
  

  Secara umum, itu kuat, tetapi tidak universal.

  
  
  
  

• Notepad ++ . Saya tidak ingat apa yang mencegahnya beralih.

• SublimeText3 , 2013. Alat peretas - pekerjaan luar biasa, dana minimum, tetapi perlu banyak diingat .

  
  
  Tayangan

  
  (+) Kontrol minimum.
  (-) Pengaturan berbeda "tempat mencari" semuanya dalam satu bidang. Penting untuk memperhitungkan interaksi mereka.
  (-) Hanya dialog terlampir .
  (+) Hasilnya langsung jatuh ke tab teks, dan hasilnya visual.
  (-) Memperbaiki hasil format: path lengkap dan nama file, kemudian baris ditemukan di dalamnya. Dari lokalisasi fragmen yang ditemukan hanya ada nomor baris.
  (+) Ada pengaturan "Konteks", sehingga garis yang ditemukan dengan tetangga masuk ke dalam Hasil.

  
  
  
  

Ada pria seperti itu

Berdasarkan prinsip "Tidak ada alat yang sempurna? Buat," mengubah arah upaya.
Dia mulai memperhatikan responsif para pengembang. Dan pada 2012, saya beruntung dengan SynWrite .

Satu-satunya pengembang, Alexei Torgashin, menerima sebagian besar ide, dibuat dengan cepat dan efisien. Waktu implementasi yang khas adalah satu atau dua hari. Di forum saya bertanya kepadanya tentang hasil akhir, kemudian sekitar satu lagi, lalu sekitar sepuluh, dan lebih ... Di suatu tempat di selusin ketiga saya menyadari bahwa kami memiliki pertemuan yang baik .

Dari kiriman saya, Alexey membawa pencarian file ke keadaan seperti itu ( SynWrite , 2016)

"Apa yang kamu butuhkan, lebih tua?"

Dengan SynWrite, pencarian menjadi jauh lebih nyaman. Seperti yang Anda tahu, nafsu makan datang dengan makan, jadi Daftar Keinginan saya berlipat ganda. Itu hanya sikap pengembang, ikan mas saya, terhadap mereka lebih dan lebih kritis - "Laut Hitam Dihitamkan . "

Itulah yang ingin saya dapatkan

1. Pastikan untuk segera membutuhkan hasilnya dalam bentuk teks (untuk diproses lebih lanjut).
2. Hasilnya harus mandiri! Sehingga mereka bisa diselamatkan, ditutup, dibuka - dan mereka tetap segar , yaitu siap untuk bekerja.
3. Kami membutuhkan pencarian di file pada disk dan di file yang terbuka (dimodifikasi).
4. Dialog dalam menyelesaikan masalah sederhana harus padat. Secara khusus, kontrol untuk "penggantian" dan pengaturan langka tidak boleh mengganggu pencarian normal.
5. Diperlukan opsi untuk hasil bersama dengan baris yang berdekatan .
6. Mode "deskripsi lengkap satu hasil dalam satu baris" diperlukan (untuk diproses lebih lanjut).
7. Informasi bantuan tentang cara mengisi bidang tidak diperlukan di file eksternal atau halaman cloud, tetapi di sana, misalnya, di tooltips.

Lakukan sendiri!

Saya beruntung lagi. Alex membuat editor CudaText baru dan mengacaukan API Python .

Akhirnya, Anda bisa melakukan apa saja sesuka Anda dalam bentuk plugin dengan Python.

Versi pertama dirilis pada Mei 2016.

Inilah yang saya terapkan sekarang

Menerapkan semua Daftar Keinginan dari daftar "Apa yang Anda inginkan."

(1) Hasilnya dapat dilihat baik di dalam dialog, atau segera output ke file (jika [x] Send ).

(2) Hasilnya menggambarkan diri sendiri. Dalam teks

informasi yang cukup untuk mengetahui nama file lengkap dan lokasi fragmen yang ditemukan.
1:21:6 berarti: 1 baris, 21 kolom, panjang fragmen 6.

Plugin dapat mengekstrak dan menggunakan informasi ini.

(3) Ada pencarian pada dokumen yang belum disimpan. Untuk melakukan ini, baris khusus <Open Files> dimasukkan dalam bidang In folder (singkatan <Tabs> dan <t> ).

(4) Anda dapat menyembunyikan kontrol yang diperlukan untuk menentukan file yang dikecualikan, untuk melakukan penggantian, untuk menampilkan hasil dan kode sumber dalam dialog.

(7) Dalam tooltips, tanda tangan ke bidang yang diisi bebas memiliki penjelasan

Menerapkan banyak potongan yang berbeda.

• Kedalaman keberangkatan dapat berupa +1 level nol ( Only ), penuh ( +All ), atau dari +1 level 1 ( +1 level ) hingga 5 ( +5 levels ).

  
  

• Opsi pencarian yang jarang digunakan muncul di For search

  
  

 •     ** / ** . •      . •         / . ![fif_first](https://user-images.githubusercontent.com/7419630/42456464-b0448f20-839d-11e8-8876-435fdfead1ad.png) •   ,        (  ). 

• Jika hasilnya tidak akan muncul di dalam dialog ( [x] Send ), maka ada parameter tambahan untuk mereka

 • `Report to` -    ,    ,        . • `Append` -   . • `Tree type` -      `<path><file><r:c:l><line>`,   `<><><><  >`  ,    (" "-6).      ![fif_help_tree](https://user-images.githubusercontent.com/7419630/42456892-a7d867c0-839e-11e8-87f2-2b9ce6b5c530.png) • `Align (r:c:l)` -     `<r:c:l>` ,   `<  >`    . : ![fif_align](https://user-images.githubusercontent.com/7419630/42616450-036e3ae6-85b7-11e8-861a-cf27a3a07c7a.png) • `Add context` -     (" "-5). 

• Anda dapat mengingat parameter pencarian - buat preset . Lima preset pertama diterapkan oleh Ctrl+1 (.. 5 ), sisanya - dari menu atau dialog Presets

  
  
  preset dialog

  

  
  
  
  

• Anda dapat mengingat tempat / ukuran dialog / kontrol - lakukan Tata Letak. Lima Layout pertama diterapkan oleh Alt+1 (.. 5 ), sisanya - dari menu.

  
  

• Hampir semua yang ada dalam dialog dapat dilakukan tanpa mouse . Untuk ini ada

  
  
  Tombol cepat

  

  
  
  
  

• Untuk tim ada

  
  
  Menu

  Tombol hamburger hanyalah "=" dengan garis bawah, sehingga tersedia oleh Alt+= .
  

  
  
  
  

• Proses pencarian dibagi menjadi tiga fase berturut-turut:
  • koleksi file yang sesuai dihasilkan,
  • fragmen diekstraksi dari file,
  • laporan tentang hasil diisi.
  Informasi tentang setiap fase dan perubahannya ditampilkan di kontrol status.
  Esc memungkinkan Anda untuk hanya mengganggu fase saat ini dan pergi ke yang berikutnya dengan akumulasi data.

  
  

• Selain parameter normal yang ditentukan pengguna, ada banyak opsi yang jarang diubah. Sekarang ada 19 dari mereka dan bagi mereka dialog yang terpisah

  
  
  Dialog opsi

  
  Misalnya, di antara opsi ada seperti:
  • Gunakan teks yang dipilih untuk mengisi bidang Find what saat membuka dialog.
  • Mengganggu semua fase pencarian dengan satu ESC .
  • Tutup dialog saat mencari dan mengeluarkan hasil ke file.
  • Perkecil hasil sebelumnya saat menambahkan yang baru ke file yang sama.
  • Simpan semua parameter pencarian di baris pertama hasil. Ini memungkinkan Anda untuk memuatnya nanti ke dalam dialog.
  • Lewati file yang lebih besar dari ukuran yang ditentukan.
  • Atur gaya untuk fragmen yang ditemukan. Warna / keberanian / kecenderungan teks yang tersedia, warna latar belakang, gaya bingkai di setiap sisi. Pada gambar di atas, gaya "bingkai dengan titik-titik di bawah fragmen" diatur.

  
  
  
  

• Beberapa perintah plugin berfungsi sebelum dan sesudah dialog.

 • `Find in *` -        . • `Navigate to *` -     ,    ,   . • `Jump to *` -   /    ,     ,     . • `Configure *` -        ,       ![fif_dclk](https://user-images.githubusercontent.com/7419630/42460070-aa1c5f26-83a5-11e8-9103-11f676dcf08a.png) 

CudaText dan Python

Beberapa kata tentang platform tempat plug-in saya tumbuh.

Alexey Torgashin membuat SynWrite di Delphi. Setengah dari kode editor ini dilisensikan dari pengembang lain, dan ini mencegah penerapan ide-ide baru. Dan Delphi dibayar. Karena itu, Alex beralih ke Free Pascal dan IDE Lazarus , mengimplementasikan bagian-bagian yang hilang dengan sendirinya dan menciptakan CudaText pada 2015, dan SynWrite membeku. Kesempatan untuk memulai dari awal digunakan dengan bijaksana - ia membuat beberapa perbaikan desain yang kuat.

1. Pengaturan mulai ditumpangkan di lapisan: default , umum , lex , file saat ini . Mereka mulai disimpan di json , tetapi tidak ini . Mengubah pengaturan telah menjadi pengeditan teks biasa dalam format json .
2. Kernel menyingkirkan sejumlah besar layanan non-kritis. Secara khusus, dari pencarian file, makro, memanggil utilitas eksternal, konfigurator menu, snippet, sortir, favorit, dll.
3. Untuk membuat layanan seperti itu, kernel menyediakan API Python, yang mencakup perpustakaan GUI. Sekarang plugin telah mengimplementasikan semua layanan sebelumnya dan menambahkan banyak yang baru.
4. Selain itu, inti itu sendiri telah menjadi multi-modul. Ada komponen marker, bookmark, atribut untuk kurung, dll.

Pengaruh Teks Sublim terlihat jelas di sini. Sejauh yang saya tahu, Alexey tidak menyembunyikan bahwa dia memperhitungkan ide-ide dari Sublime dan plugin-nya. Dia juga melirik Atom dan Kurung.

Itu ternyata berjalan dengan baik, tetapi mengingat produktivitas tinggi dan responsif Alexey, itu sangat baik. Untuk menjelaskan produktivitas dan daya tanggap seperti apa yang sedang kita bicarakan, saya akan memberikan beberapa fakta:

• Alexei dibuat: lexers - 201, linter - 34, snippet-sets - 12, plug-in - 93.
• Sejak Oktober 2015, ada lebih dari 1.200 keinginan (tidak ada keluhan) di GitHub , yang lebih dari 90% dipenuhi.

CudaText gratis, open source, ada rakitan untuk Win / Linux / Mac / BSD. Saya sendiri hanya menggunakan versi Win, tetapi saya melihat keinginan dan keluhan dari pengguna dengan Linux dan Mac. Pada Lazarus yang sama, omong-omong, Total Commander ditulis.

Sangat menarik untuk membandingkan API Python untuk Sublime dan CudaText . Mereka sangat berbeda.

• Sublime memiliki gaya objek tipe DOM.

• CudaText memiliki gaya prosedural seperti API OS, misalnya, WIN32.

Rupanya perbedaan ini berasal dari bahasa implementasi. Jika editor itu sendiri diimplementasikan dalam Python, maka gaya DOM dari API itu alami - Anda dapat menyimpan tautan ke objek. Dan jika editor dalam Pascal, maka itu hanya dapat disimpan oleh penangan.

• Sublime API tidak memiliki GUI. Plugin ini rupanya dapat menggunakan Python GUI (Tk? WxPython? Qt?), Tetapi gayanya akan kontras dengan Sublime.

• CudaText menyediakan plugin GUI dalam gaya keseluruhan aplikasi. Pertama, ada banyak gudang kendali dasar: checklistbox , listview , checklistview , treeview dan, tentu saja, tombol biasa, cek, editor tunggal dan multi-baris, kotak kombo, dll. Kedua, ada kemampuan untuk menanamkan komponen CudaText di GUI. Pada gambar di atas adalah kontrol status, menu lokal dan kontrol editor dengan hasil / sumber. Pelengkap seperti itu dengan GUI Python murni sama sekali tidak mungkin.

Apakah ada batasannya?

Kira-kira sekali setiap dua hingga tiga bulan, dan ini berlangsung, saya ingat, sudah dua setengah tahun, menurut saya bahwa "ini adalah final" - dialog dijilat, hasilnya ditampilkan dalam semua cara, ada semua perintah yang berguna. Tetapi karena alat ini terus digunakan, karena hampir semua fitur-fiturnya digunakan, sementara tangan mengklik pencarian berikutnya atau mempelajari hasil selanjutnya, kepala mencari perbaikan baru. Dan menemukan!

Selain itu, saya tertarik untuk memahami apakah pikiran kolektif dapat menyarankan gerakan baru dalam permainan ini. Karena itu, saya menyimpulkan dengan pertanyaan untuk sesama programmer:
Apa lagi yang bisa ditambahkan ke "pencarian file" di dalam editor teks?