How far away are dreams of the perfect “file search”

Do you often run a search on text files? I have been every day for more than 25 years.

My tasks are very different in complexity and scope.

First of all, as a programmer, I, of course, need searches in codes. These tasks are simple (sets of folders and files are small) and fast (results appear almost immediately).

Secondly, as an operator, I have to search for hundreds (sometimes thousands) of folders among thousands (sometimes hundreds of thousands) of files. These are difficult tasks both in terms of results and the time they are received. Usually the results of such searches still require further manual or software processing.

All work happens in Windows.

I will tell you where the desire to have a suitable tool for such tasks has led me.

In the beginning was TextPad

For over 10 years, TextPad has been my primary lightweight tool.
Then (before and after 2000), he did an excellent job.

File search looked like this ( TextPad , 2004)

Reels and comparisons

The limitations of the TextPad and its freezing led to constant sampling by other editors.
Now I do not remember all tried, but among them were:

• MS Visual Studio . Heavy Monster.
• Eclipse Also a monster.

• IntelliJ IDEA . Charming. Served and serves as a supplier of examples of how to make it convenient .

  
  
  Impressions

  That old IDEA is already lost. For comparison, the current implementation in PyCharm , 2017.1.3
  
  (+) Unimaginable number of settings and modes.
  (+) Self-sustainability of the dialogue: the results, source codes, and search statistics are visible.
  (-) There is no limit on the depth of searching by folders - either one or all at once.
  (-) No (I don’t know how) search in several folders.
  (-) No (I don’t know how) to display the results in text format.

  
  

  In general, it is powerful, but not universal.

  
  
  
  

• Notepad ++ . I do not remember what prevented him from switching.

• SublimeText3 , 2013. The hacking tool is an excellent job, with a minimum of money, but it takes a lot to keep in mind .

  
  
  Impressions

  
  (+) Minimum controls.
  (-) Different settings "where to look" all in one field. Need to take into account their interaction.
  (-) Only attached dialog.
  (+) The results immediately fall into the text tab, and they are visual.
  (-) Fixed format results: full path and file name, then strings found in it. From the localization of the found fragments there are only line numbers.
  (+) There is a "Context" setting to match the found lines with the neighbors to the Results.

  
  
  
  

There is such a guy

Taking the principle of "There is no perfect tool? Create", changed the direction of effort.
Began to pay attention to the responsiveness of developers. And in 2012 I was lucky with SynWrite .

The only developer, Alexey Torgashin, accepted most of the ideas, did it quickly and efficiently. Typical implementation time is a day or two. At the forum I asked him about finishing work, then about one more, then about ten more, and more ... Somewhere in the top ten, I realized that we had a good meeting .

From my submission, Alexey brought the file search to this state ( SynWrite , 2016)

"What do you want, older?"

With SynWrite, search has become much easier. As you know, the appetite comes with eating, so my Wishlist all multiplied. That's just the attitude towards them from the developer, my golden fish , was all the more critical - "The black blue sea" .

That's what I wanted to get

1. Be sure to need the results immediately in text form (for further processing).
2. Results must be self-sufficient! So that they can be saved, closed, opened - and they remained fresh , that is, ready to work.
3. Need to search the files on the disk and in the open (modified) files.
4. The dialogue in solving simple problems should be compact. In particular, controls for "replacements" and rare settings should not interfere with a normal search.
5. Be sure to need the option for results along with adjacent lines .
6. You need the mode "full description of one result in one line" (for further processing).
7. Background information on how to fill in the fields is not needed in an external file or a cloud page, but right there, for example, in tooltips.

Do it yourself!

I was lucky again. Alexey created the new CudaText editor and screwed the Python API to it.

Finally, you could do everything as you want in the form of a plug-in on Python.

The first version was released in May 2016.

Here is what I apply now.

Implemented all Wishlist from the list of "What you need."

(1) The results can be seen either within the dialogue, or immediately output to a file (if [x] Send ).

(2) The results are self-descriptive. In the text

there is enough information to find out the full file name and location of the found fragment.
1:21:6 means: 1 line, 21 column, fragment length 6.

The plugin can extract and use this information.

(3) There is a search for unsaved documents. To do this, the special string <Open Files> is entered in the In folder field (the <Tabs> and <t> abbreviations work).

(4) In the dialog, you can hide the controls needed to specify the excluded files, to perform replacements, to display the results and source codes.

(7) In tooltips, signatures to freely filled fields have explanations.

Implemented many more different pieces .

• The depth of the traversal can be zero ( Only ), full ( +All ), or from 1 ( +1 level ) to 5 ( +5 levels ) levels.

  
  

• Rarely used search options appear by For search

  
  

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

• If the results will not appear inside the dialog ( [x] Send ), then there are additional parameters for them

 • `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). 

• You can remember the search parameters - make presets . The first five presets are applied by Ctrl+1 (.. 5 ), the rest are from the Presets menu or dialog.

  
  
  Presets dialog

  

  
  
  
  

• You can memorize the place / size of the dialog / controls - do Layout. The first five layouts are applied by Alt+1 (.. 5 ), the rest are from the menu.

  
  

• Almost everything in the dialogue can be done without a mouse . For this there is

  
  
  Hotkeys

  

  
  
  
  

• For teams there is

  
  
  Menu

  The hamburger button is just an "=" with underscore, so it is accessible by Alt+= .
  

  
  
  
  

• The search process is divided into three successive phases:
  • a collection of suitable files is formed,
  • fragments are extracted from files,
  • a report on the results is completed.
  Information about each phase and their change is displayed in the status control.
  Esc allows you to interrupt only the current phase and move on to the next with already accumulated data.

  
  

• In addition to the usual user-defined parameters, there are many rarely changed options. Now there are 19 of them and for them a separate dialogue

  
  
  Options dialog

  
  For example, among the options there are:
  • Use highlighted text to fill in the Find what field when opening a dialog.
  • Interrupt all search phases with one ESC .
  • Close the dialog when searching successfully and outputting results to a file.
  • Collapse previous results when adding new ones to the same file.
  • Save all search parameters in the first row of results. This allows them to be loaded into the dialog later.
  • Skip files larger than specified.
  • Set the style for the found fragments. Available color / fatness / inclination of the text, background color, style of the frame on each side. In the pictures above, the frame-dotted-under-fragment style is set.

  
  
  
  

• Some teams of the plugin work before and after the dialogue.

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

CudaText and Python

A few words about the platform on which my plugin has grown.

Alexey Torgashin made SynWrite at Delphi. Half of the codes of this editor were licensed from another developer, and this prevented the introduction of new ideas. And Delphi paid. Because of this, Alexey switched to Free Pascal and IDE Lazarus , implemented the missing parts independently and created CudaText in 2015, and SynWrite froze. The opportunity to start from scratch was used sensibly - he made some strong design improvements.

1. Settings began to be superimposed by layers: default , general , lex , current file . They began to be stored in json , but not in ini . Changing the settings has become the usual text editing in json format.
2. The kernel got rid of a huge number of non-critical services. In particular, from file search, macros, calling external utilities, menu configurators, snippets, sorts, favorites, etc.
3. To create such services, the kernel provides the Python API, which includes a GUI library. Now all previous services have been implemented with plugins and a lot of new ones have been added.
4. In addition, the core itself has become multi-modular. There are components of markers, bookmarks, attributes for brackets, etc.

Here you can clearly see the influence of Sublime Text . As far as I know, Alexey does not hide that he takes into account ideas from Sublime and its plug-ins. At Atom and Brackets, he also glances.

It turned out in itself is good, but given the high productivity and responsiveness of Alexei - great. To clarify what kind of productivity and responsiveness we are talking about, here are some facts:

• Alexey created: lexers - 201, linters - 34, snippet-sets - 12, plug-ins - 93.
• Since October 2015, there have been more than 1,200 wishes (no complaints) on the GitHub , of which more than 90% are satisfied.

CudaText is free, open source, there are builds for Win / Linux / Mac / BSD. I myself use only the Win-version, but I see suggestions and complaints from users with Linux and Mac. On the same Lazarus written, by the way, Total Commander .

It is interesting to compare Python API with Sublime and with CudaText . They are completely different.

• For Sublime, an object style of type DOM.

• With CudaText, a procedural style of the OS API type, for example, WIN32.

Apparently this difference comes from implementation languages. If the editor itself is implemented on Python, then the DOM API style is natural for it - you can store references to objects. And if the editor is in Pascal, then he can only store handlers.

• Sublime API has no GUI. The plugin can apparently use the Python GUI (Tk? WxPython? Qt?), But the style will be contrasted with Sublime.

• CudaText provides for GUI plugins in the general style of the application. First, there is a rich arsenal of basic controls: checklistbox , listview , checklistview , treeview and, of course, the usual buttons, checks, single and multi-line editors, combo boxes, etc. Secondly, it is possible to embed CudaText components in the GUI. In the snapshots above, these are status controls, local menus, and editor controls with results / sources. Such a complementarity of pure Python GUI is not at all achieved.

Is there a limit?

About once every two or three months, and it’s been, I remind, for two and a half years, it seems to me that “this is the final” - the dialogue has been licked out, the results are shown in all ways, there are all useful commands. But since this tool is constantly in operation, since almost all of its features are applied, so long as the hands click on another search or study the next results, the head is looking for new improvements. And finds!

In addition, it is interesting for me to understand - can the collective mind suggest new moves in this game . Therefore, I end with a question for fellow programmers:
What else is useful to add to the "search for files" inside a text editor?