A que distância estão os sonhos da "pesquisa de arquivos" perfeita

Você costuma executar uma pesquisa em arquivos de texto? I - todos os dias há mais de 25 anos.

Minhas tarefas são muito diferentes em complexidade e escopo.

Primeiro, como programador, é claro, preciso de pesquisas nos códigos. Essas tarefas são simples (conjuntos de pastas e arquivos são pequenos) e rápidos (os resultados aparecem quase imediatamente).

Em segundo lugar, como operador, tenho que pesquisar centenas (às vezes milhares) de pastas entre milhares (às vezes centenas de milhares) de arquivos. Essas são tarefas difíceis , tanto em termos de volume de resultados quanto no tempo em que foram recebidos. Normalmente, os resultados dessas pesquisas ainda exigem processamento manual ou de software adicional.

Todo o trabalho é feito no Windows.

Vou lhe dizer onde o desejo me levou a ter uma ferramenta adequada para essas tarefas.

No começo era o TextPad

Por mais de 10 anos, o TextPad tem sido minha principal ferramenta fácil .
Então (antes e pouco depois de 2000) ele fez um excelente trabalho.

A pesquisa de arquivos ficou assim ( TextPad , 2004)

Bobinas e comparações

As limitações do TextPad e seu congelamento levaram a testes constantes de outros editores.
Agora você não consegue se lembrar de todos os experimentados, mas entre eles estavam:

• MS Visual Studio . Monstro pesado.
• Eclipse Também um monstro.

• IntelliJ IDEA . Charmoso. Serviu e serve como um provedor de exemplos de como você pode fazê- lo convenientemente .

  
  
  Impressões

  Essa velha IDÉIA já está perdida. Para comparação, a implementação atual no PyCharm , 2017.1.3
  
  (+) Um número inimaginável de configurações e modos.
  (+) Auto-suficiência do diálogo: resultados, códigos-fonte e estatísticas de pesquisa são visíveis.
  (-) Não há restrições quanto à profundidade da pesquisa em pastas - uma ou todas de uma vez.
  (-) Não (não sei o caminho) pesquise em várias pastas.
  (-) Nenhuma saída (não sei o caminho) dos resultados em formato de texto.

  
  

  Em geral, é poderoso, mas não universal.

  
  
  
  

• Notepad ++ . Não lembro o que o impediu de mudar.

• SublimeText3 , 2013. Uma ferramenta hacker - excelente trabalho, um mínimo de fundos, mas é preciso ter muito em mente .

  
  
  Impressões

  
  (+) Controles mínimos.
  (-) Diferentes configurações "onde procurar" em um único campo. É necessário levar em consideração sua interação.
  (-) Apenas diálogo em anexo .
  (+) Os resultados caem imediatamente na guia de texto e são visuais.
  (-) Resultados de formato fixo: caminho completo e nome do arquivo, depois as linhas encontradas nele. Da localização dos fragmentos encontrados, existem apenas números de linha.
  (+) Existe uma configuração "Contexto", para que as linhas encontradas com os vizinhos entrem nos Resultados.

  
  
  
  

Existe um cara

Com base no princípio de "Nenhuma ferramenta perfeita? Criar", mudou a direção dos esforços.
Ele começou a prestar atenção à capacidade de resposta dos desenvolvedores. E em 2012, tive sorte com o SynWrite .

O único desenvolvedor, Alexei Torgashin, aceitou a maioria das idéias, feitas de maneira rápida e eficiente. Um horário típico de implementação é de um dia ou dois. No fórum, perguntei a ele sobre o término, depois mais um, depois dez e mais ... Em algum momento da terceira dúzia, percebi que tínhamos uma boa reunião .

Do meu envio, Alexey levou a busca de arquivos a esse estado ( SynWrite , 2016)

"O que você precisa, mais velho?"

Com o SynWrite, a pesquisa se tornou muito mais conveniente. Como você sabe, o apetite vem com a comida, então minha lista de desejos se multiplica. Essa é apenas a atitude do desenvolvedor, meu peixe dourado , em relação a eles, que é cada vez mais crítico - "O Mar Negro foi enegrecido" .

Era isso que eu queria conseguir

1. Certifique-se de precisar dos resultados imediatamente em forma de texto (para processamento adicional).
2. Os resultados devem ser auto-suficientes! Para que pudessem ser salvos, fechados, abertos - e permaneceram frescos , isto é, prontos para o trabalho.
3. Precisamos de uma pesquisa nos arquivos do disco e nos arquivos abertos (modificados).
4. O diálogo na solução de problemas simples deve ser compacto. Em particular, os controles para "substituições" e configurações raras não devem interferir em uma pesquisa normal.
5. Necessariamente precisa de uma opção para os resultados junto com as linhas adjacentes .
6. É necessário o modo "descrição completa de um resultado em uma linha" (para processamento adicional).
7. As informações de ajuda sobre como preencher os campos são necessárias não em um arquivo externo ou página em nuvem, mas ali, por exemplo, em dicas de ferramentas.

Faça você mesmo!

Eu tive sorte novamente. Alex criou um novo editor CudaText e parafusou a API do Python nele.

Finalmente, você pode fazer tudo o que quiser na forma de um plug-in no Python.

A primeira versão foi lançada em maio de 2016.

Aqui está o que eu aplico agora

Implementou toda a lista de desejos na lista "O que você deseja".

(1) Os resultados podem ser vistos dentro da caixa de diálogo ou imediatamente gerados em um arquivo (se [x] Send ).

(2) Os resultados são auto-descritivos. No texto

informações suficientes para descobrir o nome completo do arquivo e a localização do fragmento encontrado.
1:21:6 significa: 1 linha, 21 colunas, comprimento do fragmento 6.

O plug-in é capaz de extrair e usar essas informações.

(3) Há uma pesquisa em documentos não salvos. Para fazer isso, uma linha especial <Open Files> é inserida no campo In folder (as abreviações <Tabs> e <t> ).

(4) Você pode ocultar os controles necessários para especificar arquivos excluídos, executar substituições, exibir resultados e códigos-fonte em uma caixa de diálogo.

(7) Nas dicas de ferramentas, as assinaturas de campos preenchidos livremente têm explicações

Implementou muito mais peças diferentes.

• A profundidade da partida pode ser zero ( Only ), completa ( +All ) ou de 1 ( +1 level ) a 5 ( +5 levels ).

  
  

• As opções de pesquisa raramente usadas aparecem em For search

  
  

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

• Se os resultados não aparecerem dentro da caixa de diálogo ( [x] Send ), existem parâmetros adicionais para eles

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

• Você pode se lembrar dos parâmetros de pesquisa - faça predefinições . As cinco primeiras predefinições são aplicadas por Ctrl+1 (.. 5 ), o restante - no menu ou na caixa de diálogo Presets

  
  
  predefinições de diálogo

  

  
  
  
  

• Você pode se lembrar do local / tamanho da caixa de diálogo / controles - faça o Layout. Os cinco primeiros Layout são aplicados por Alt+1 (.. 5 ), o restante - no menu.

  
  

• Quase tudo no diálogo pode ser feito sem o mouse . Para isso existe

  
  
  Teclas de atalho

  

  
  
  
  

• Para equipes há

  
  
  Menu

  O botão hambúrguer é apenas um "=" com sublinhado, portanto está disponível por Alt+= .
  

  
  
  
  

• O processo de pesquisa é dividido em três fases consecutivas:
  • uma coleção de arquivos adequados é gerada,
  • fragmentos são extraídos de arquivos,
  • um relatório sobre os resultados é preenchido.
  As informações sobre cada fase e suas alterações são exibidas no controle de status.
  Esc permite interromper apenas a fase atual e passar para a próxima com os dados acumulados.

  
  

• Além dos parâmetros normais definidos pelo usuário, existem muitas opções raramente alteradas. Agora existem 19 deles e para eles um diálogo separado

  
  
  Caixa de diálogo Opções

  
  Por exemplo, entre as opções, existem:
  • Use o texto selecionado para preencher Find what campo Find what , ao abrir a caixa de diálogo.
  • Interrompa todas as fases da pesquisa com um ESC .
  • Feche a caixa de diálogo ao pesquisar e produzir resultados para um arquivo.
  • Recolha os resultados anteriores ao adicionar novos ao mesmo arquivo.
  • Salve todos os parâmetros de pesquisa na primeira linha de resultados. Isso permite que você os carregue posteriormente na caixa de diálogo.
  • Ignore arquivos maiores que o tamanho especificado.
  • Defina o estilo para os fragmentos encontrados. Cor / negrito / inclinação disponível do texto, cor do plano de fundo, estilo do quadro de cada lado. Nas figuras acima, o estilo "moldura com pontos sob o fragmento" é definido.

  
  
  
  

• Alguns comandos de plug-in funcionam antes e depois da caixa de 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 e Python

Algumas palavras sobre a plataforma na qual meu plug-in cresceu.

Alexey Torgashin fez SynWrite em Delphi. Metade dos códigos deste editor foram licenciados por outro desenvolvedor, o que impediu a implementação de novas idéias. E Delphi é pago. Por causa disso, Alex mudou para o Free Pascal e o IDE Lazarus , implementou as partes ausentes por conta própria e criou o CudaText em 2015, e o SynWrite congelou. A oportunidade de começar do zero foi sensata - ele fez várias melhorias significativas no design.

1. As configurações começaram a ser sobrepostas em camadas: padrão , geral , lex , arquivo atual . Eles começaram a ser armazenados em json , mas não ini . Alterar as configurações tornou-se a edição de texto usual no formato json .
2. O kernel se livrou de um grande número de serviços não críticos. Em particular, de pesquisas de arquivos, macros, utilitários externos de chamada, configurador de menus, trechos, classificações, favoritos, etc.
3. Para criar esses serviços, o kernel fornece a API Python, que inclui a biblioteca da GUI. Agora, os plug-ins implementaram todos os serviços anteriores e adicionaram muitos novos.
4. Além disso, o próprio núcleo tornou-se multi-módulo. Existem componentes de marcadores, marcadores, atributos para colchetes, etc.

A influência do texto sublime é claramente visível aqui. Até onde eu sei, Alexey não esconde que ele leva em conta as idéias do Sublime e seus plugins. Ele também olha para Atom e Brackets.

O resultado foi bom em si, mas considerando a alta produtividade e capacidade de resposta de Alexey, foi excelente. Para explicar que tipo de produtividade e capacidade de resposta estamos falando, apresentarei alguns fatos:

• Alexei criou: lexers - 201, linter - 34, snippet-sets - 12, plug-ins - 93.
• Desde outubro de 2015, houve mais de 1.200 desejos (sem queixas) no GitHub , dos quais mais de 90% estão satisfeitos.

O CudaText é gratuito, de código aberto, existem assemblies para Win / Linux / Mac / BSD. Eu mesmo uso apenas a versão Win, mas vejo os desejos e reclamações dos usuários com Linux e Mac. No mesmo Lazarus, a propósito, Total Commander está escrito.

É interessante comparar as APIs Python para Sublime e CudaText . Eles são completamente diferentes.

• Sublime tem um estilo de objeto do tipo DOM.

• O CudaText possui um estilo de procedimento, como o API OS, por exemplo, WIN32.

Aparentemente, essa diferença vem das linguagens de implementação. Se o próprio editor for implementado em Python, o estilo DOM da API é natural para ele - você pode armazenar links para objetos. E se o editor estiver em Pascal, ele poderá ser armazenado apenas por manipuladores.

• A API Sublime não possui uma GUI. Aparentemente, o plug-in pode usar a GUI do Python (Tk? WxPython? Qt?), Mas o estilo contrastará com o Sublime.

• O CudaText fornece plugins de GUI no estilo geral do aplicativo. Em primeiro lugar, existe um rico arsenal de controles básicos: checklistbox , listview , checklistview , treeview e, é claro, botões comuns, cheques, editores de uma e de várias linhas, caixas de combinação, etc. Em segundo lugar, existe a capacidade de incorporar componentes CudaText na GUI. Nas figuras acima, há um controle de status, um menu local e um editor com os resultados / fonte. Essa complementação com uma GUI Python pura não é de todo possível.

Existe um limite?

Cerca de uma vez a cada dois a três meses, e isso dura, lembro-me, já há dois anos e meio, parece-me que "este é o final" - o diálogo é lambido, os resultados são mostrados de todas as formas, todos os comandos são úteis. Mas como essa ferramenta está em uso constante, uma vez que quase todos os seus recursos são usados, enquanto as mãos clicam na próxima pesquisa ou estudam os próximos resultados, o chefe está procurando novas melhorias. E encontra!

Além disso, estou interessado em entender se a mente coletiva pode sugerir novos movimentos neste jogo . Portanto, concluo com uma pergunta para colegas programadores:
O que mais pode ser adicionado à "pesquisa de arquivos" dentro do editor de texto?