¿Qué tan lejos llevan los sueños de la perfecta "búsqueda de archivos"

¿Sueles realizar búsquedas en archivos de texto? Yo, todos los días durante más de 25 años.

Mis tareas son muy diferentes en complejidad y alcance.

Primero, como programador, por supuesto, necesito búsquedas en los códigos. Estas tareas son simples (los conjuntos de carpetas y archivos son pequeños) y rápidas (los resultados aparecen casi de inmediato).

En segundo lugar, como operador, tengo que buscar cientos (a veces miles) de carpetas entre miles (a veces cientos de miles) de archivos. Estas son tareas difíciles tanto en términos del volumen de resultados como en el momento en que se recibieron. Por lo general, los resultados de dichas búsquedas aún requieren más procesamiento manual o de software.

Todo el trabajo se realiza en Windows.

Te diré a dónde me llevó el deseo de tener una herramienta adecuada para tales tareas.

Al principio era TextPad

Durante más de 10 años, TextPad ha sido mi principal herramienta fácil .
Luego (antes y poco después del 2000) hizo un excelente trabajo.

La búsqueda de archivos se veía así ( TextPad , 2004)

Carretes y comparaciones

Las limitaciones de TextPad y su congelación llevaron a constantes pruebas de otros editores.
Ahora no puedes recordar a todos los probados, pero entre ellos estaban:

• MS Visual Studio . Monstruo pesado
• Eclipse También un monstruo.

• IDEA IntelliJ . Encantador. Sirve y sirve como proveedor de ejemplos de cómo puede hacerlo convenientemente .

  
  
  Impresiones

  Esa vieja IDEA ya está perdida. A modo de comparación, la implementación actual en PyCharm , 2017.1.3
  
  (+) Un número inimaginable de configuraciones y modos.
  (+) Autosuficiencia del diálogo: los resultados, los códigos fuente y las estadísticas de búsqueda son visibles.
  (-) No hay restricciones en la profundidad de búsqueda en las carpetas, ya sea una o todas a la vez.
  (-) No (no sé cómo) buscar en varias carpetas.
  (-) No (no sé el camino) salida de los resultados en formato de texto.

  
  

  En general, es poderoso, pero no universal.

  
  
  
  

• Bloc de notas ++ . No recuerdo qué le impidió cambiar.

• SublimeText3 , 2013. Una herramienta de hackers : excelente trabajo, un mínimo de fondos, pero se necesita mucho para tener en cuenta .

  
  
  Impresiones

  
  (+) Controles mínimos.
  (-) Configuraciones diferentes "dónde buscar" todo en un campo. Es necesario tener en cuenta su interacción.
  (-) Solo diálogo adjunto .
  (+) Los resultados caen inmediatamente en la pestaña de texto y son visuales.
  (-) Resultados de formato fijo: ruta completa y nombre de archivo, luego las líneas encontradas en él. De la localización de los fragmentos encontrados solo hay números de línea.
  (+) Hay una configuración "Contexto", de modo que las líneas encontradas con los vecinos entran en los Resultados.

  
  
  
  

Hay tal chico

Basado en el principio de "¿Ninguna herramienta perfecta? Crear", cambió la dirección de los esfuerzos.
Comenzó a prestar atención a la capacidad de respuesta de los desarrolladores. Y en 2012, tuve suerte con SynWrite .

El único desarrollador, Alexei Torgashin, aceptó la mayoría de las ideas, realizadas de forma rápida y eficiente. Un tiempo de implementación típico es uno o dos días. En el foro le pregunté sobre el final, luego sobre uno más, luego sobre diez y más ... En algún lugar de la tercera docena me di cuenta de que teníamos una buena reunión .

Desde mi presentación, Alexey llevó la búsqueda de archivos a dicho estado ( SynWrite , 2016)

"¿Qué necesitas, mayor?"

Con SynWrite, la búsqueda se ha vuelto mucho más conveniente. Como saben, el apetito viene con la comida, por lo que mi lista de deseos se multiplicó. Esa es solo la actitud del desarrollador, mi pez dorado , hacia ellos era cada vez más crítico: "El Mar Negro se ennegreció" .

Eso es lo que quería conseguir

1. Asegúrese de necesitar los resultados inmediatamente en forma de texto (para su posterior procesamiento).
2. ¡Los resultados deberían ser autosuficientes! Para que pudieran salvarse, cerrarse, abrirse y mantenerse frescos , es decir, listos para trabajar.
3. Necesitamos una búsqueda en los archivos en el disco y en los archivos abiertos (modificados).
4. El diálogo para resolver problemas simples debe ser compacto. En particular, los controles para "reemplazos" y configuraciones raras no deberían interferir con una búsqueda normal.
5. Necesariamente necesita una opción para los resultados junto con las filas adyacentes .
6. El modo "descripción completa de un resultado en una línea" es necesario (para su posterior procesamiento).
7. La información de ayuda sobre cómo completar los campos no es necesaria en un archivo externo o página en la nube, sino allí mismo, por ejemplo, en la información sobre herramientas.

Hazlo tu mismo!

Tuve suerte de nuevo. Alex creó un nuevo editor de CudaText y le atornilló la API de Python .

Finalmente, puede hacer todo lo que quiera en forma de complemento en Python.

La primera versión se lanzó en mayo de 2016.

Esto es lo que solicito ahora

Implementado toda la lista de deseos de la lista de "¿Qué quieres?"

(1) Los resultados se pueden ver dentro del cuadro de diálogo o inmediatamente en un archivo (si [x] Send ).

(2) Los resultados se describen a sí mismos. En el texto

información suficiente para averiguar el nombre completo del archivo y la ubicación del fragmento encontrado.
1:21:6 significa: 1 línea, 21 columnas, longitud del fragmento 6.

El complemento puede extraer y usar esta información.

(3) Hay una búsqueda en documentos no guardados. Para hacer esto, se ingresa una línea especial <Open Files> en el campo In folder (las abreviaturas <Tabs> y <t> ).

(4) Puede ocultar los controles necesarios para especificar archivos excluidos, para realizar reemplazos, para mostrar resultados y códigos fuente en un diálogo.

(7) En la información sobre herramientas, las firmas de los campos rellenados libremente tienen explicaciones

Implementado muchas más piezas diferentes.

• La profundidad de salida puede ser cero ( Only ), completa ( +All ) o de 1 ( +1 level ) a 5 ( +5 levels ) niveles.

  
  

• Las opciones de búsqueda que se usan con poca frecuencia aparecen en For search

  
  

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

• Si los resultados no aparecen dentro del cuadro de diálogo ( [x] Send ), entonces hay parámetros adicionales para ellos

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

• Puede recordar los parámetros de búsqueda: realice ajustes preestablecidos . Ctrl+1 (.. 5 ) aplica los primeros cinco ajustes preestablecidos, el resto, desde el menú o el cuadro de diálogo Presets

  
  
  ajustes preestablecidos de diálogo

  

  
  
  
  

• Puede recordar el lugar / tamaño del cuadro de diálogo / controles - hacer diseño. Los primeros cinco diseños se aplican con Alt+1 (.. 5 ), el resto, desde el menú.

  
  

• Casi todo en el diálogo se puede hacer sin un mouse . Para esto hay

  
  
  Teclas de acceso rápido

  

  
  
  
  

• Para los equipos hay

  
  
  Menu

  El botón de hamburguesa es solo un "=" con un subrayado, por lo que está disponible con Alt+= .
  

  
  
  
  

• El proceso de búsqueda se divide en tres fases consecutivas:
  • se genera una colección de archivos adecuados,
  • se extraen fragmentos de archivos,
  • se completa un informe sobre los resultados.
  La información sobre cada fase y su cambio se muestra en el control de estado.
  Esc permite interrumpir solo la fase actual y pasar a la siguiente con los datos acumulados.

  
  

• Además de los parámetros normales definidos por el usuario, hay muchas opciones que rara vez cambian. Ahora hay 19 de ellos y para ellos un diálogo separado

  
  
  Diálogo de opciones

  
  Por ejemplo, entre las opciones hay:
  • Use el texto seleccionado para completar el campo Find what al abrir el cuadro de diálogo.
  • Interrumpa todas las fases de la búsqueda con un ESC .
  • Cierre el cuadro de diálogo cuando busque y envíe resultados a un archivo.
  • Contraiga los resultados anteriores al agregar nuevos al mismo archivo.
  • Guarde todos los parámetros de búsqueda en la primera fila de resultados. Esto le permite luego cargarlos en el cuadro de diálogo.
  • Omitir archivos más grandes que el tamaño especificado.
  • Establecer el estilo para los fragmentos encontrados. Color disponible / negrita / inclinación del texto, color de fondo, estilo de marco en cada lado. En las imágenes de arriba, se establece el estilo "marco con puntos debajo del fragmento".

  
  
  
  

• Algunos comandos del complemento funcionan antes y después del diálogo.

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

CudaText y Python

Algunas palabras sobre la plataforma en la que creció mi complemento.

Alexey Torgashin hizo SynWrite en Delphi. La mitad de los códigos de este editor fueron licenciados por otro desarrollador, y esto impidió la implementación de nuevas ideas. Y a Delphi se le paga. Debido a esto, Alex cambió a Free Pascal e IDE Lazarus , implementó las partes faltantes por su cuenta y creó CudaText en 2015, y SynWrite se congeló. La oportunidad de comenzar desde cero se aprovechó con sensatez: realizó varias mejoras importantes en el diseño.

1. La configuración comenzó a superponerse en capas: predeterminada , general , lex , archivo actual . Comenzaron a almacenarse en json , pero no en ini . Cambiar la configuración se ha convertido en la edición de texto habitual en formato json .
2. El núcleo se deshizo de una gran cantidad de servicios no críticos. En particular, desde búsquedas de archivos, macros, llamadas a utilidades externas, configurador de menús, fragmentos, géneros, favoritos, etc.
3. Para crear dichos servicios, el núcleo proporciona la API de Python, que incluye la biblioteca GUI. Ahora los complementos han implementado todos los servicios anteriores y han agregado muchos nuevos.
4. Además, el núcleo mismo se ha convertido en un módulo múltiple. Hay componentes de marcadores, marcadores, atributos para corchetes, etc.

La influencia de Sublime Text es claramente visible aquí. Hasta donde yo sé, Alexey no oculta que tiene en cuenta las ideas de Sublime y sus complementos. También mira a Atom and Brackets.

Resultó bien en sí mismo, pero considerando la alta productividad y capacidad de respuesta de Alexey, fue excelente. Para explicar de qué tipo de productividad y capacidad de respuesta estamos hablando, daré algunos datos:

• Alexei creó: lexers - 201, linter - 34, snippet-sets - 12, plug-ins - 93.
• Desde octubre de 2015, ha habido más de 1,200 deseos (sin quejas) en GitHub , de los cuales más del 90% están satisfechos.

CudaText es gratuito, de código abierto, hay ensamblados para Win / Linux / Mac / BSD. Yo solo uso la versión Win, pero veo los deseos y las quejas de los usuarios con Linux y Mac. En el mismo Lázaro, por cierto, Total Commander está escrito.

Es interesante comparar las API de Python para Sublime y CudaText . Son completamente diferentes.

• Sublime tiene un estilo de objeto del tipo DOM.

• CudaText tiene un estilo de procedimiento como API OS, por ejemplo, WIN32.

Aparentemente, esta diferencia proviene de los lenguajes de implementación. Si el editor en sí se implementa en Python, entonces el estilo DOM de la API es natural: puede almacenar enlaces a objetos. Y si el editor está en Pascal, solo puede ser almacenado por manejadores.

• La API Sublime no tiene una GUI. Aparentemente, el complemento puede usar la GUI de Python (Tk? WxPython? Qt?), Pero el estilo contrastará con Sublime.

• CudaText proporciona complementos de GUI en el estilo general de la aplicación. En primer lugar, hay un rico arsenal de controles básicos: treeview checklistview , treeview checklistview , treeview checklistview , vista de treeview y, por supuesto, botones normales, controles, editores de una o varias líneas, cuadros combinados, etc. En segundo lugar, existe la posibilidad de incrustar componentes de CudaText en la GUI. En las imágenes de arriba es un control de estado, un menú local y controles de editor con los resultados / fuente. Tal complementación con una interfaz gráfica de usuario pura de Python no es posible en absoluto.

¿Hay un límite?

Aproximadamente una vez cada dos o tres meses, y esto dura, recuerdo, ya dos años y medio, me parece que "este es el final": el diálogo se lame, los resultados se muestran de todas las maneras, hay comandos útiles. Pero dado que esta herramienta se usa constantemente, ya que se utilizan casi todas sus características, mientras las manos hacen clic en la siguiente búsqueda o estudian los siguientes resultados, el jefe está buscando nuevas mejoras. Y encuentra!

Además, estoy interesado en comprender si la mente colectiva puede sugerir nuevos movimientos en este juego . Por lo tanto, concluyo con una pregunta para otros programadores:
¿Qué más se puede agregar a la "búsqueda de archivos" dentro del editor de texto?