docfd

Docfd

Recherche de documents flous multilignes TUI

Pensez à grep interactif pour les fichiers texte, les PDF, les DOCX, etc., mais basé sur des mots/jetons au lieu de regex et de lignes, afin que vous puissiez facilement rechercher sur plusieurs lignes.

Docfd vise à fournir une bonne UX via l'intégration avec des éditeurs de texte et des visionneuses PDF courants, afin que vous puissiez accéder directement à un résultat de recherche en appuyant sur une seule touche.

---

Caractéristiques

• Indexation et recherche multithread

• Recherche floue multiligne de plusieurs fichiers

• Volet d'affichage du contenu qui affiche l'extrait entourant le résultat de recherche sélectionné

• Intégration de l'éditeur de texte et de la visionneuse PDF

• Historique des commandes modifiables - réécrivez/planifiez vos actions dans l'éditeur de texte

• Restriction de la portée de la recherche : limiter la portée de la prochaine recherche en fonction des résultats de recherche actuels

• Intégration du presse-papiers

Installation

Les binaires liés statiquement pour Linux et macOS sont disponibles via les versions GitHub.

Docfd est également fourni sur les plates-formes suivantes pour Linux :

• opam
• AUR (comme docfd-bin ) par kseistrup
• « Nix (comme docfd ) » par chewblacka

La seule façon d’utiliser Docfd sous Windows à l’heure actuelle est via WSL.

Notes pour les empaqueteurs : En dehors de la chaîne d'outils OCaml pour la construction (si vous emballez à partir des sources), Docfd nécessite également les outils externes suivants au moment de l'exécution pour bénéficier de toutes les fonctionnalités :

• pdftotext de poppler-utils pour le support PDF
• pandoc pour la prise en charge des fichiers .epub , .odt , .docx , .fb2 , .ipynb , .html et .htm
• fzf pour le menu de sélection de fichiers
• wl-clibpard pour la prise en charge du presse-papiers sur Wayland
• xclip pour la prise en charge du presse-papiers sur X11

Utilisation de base

L'utilisation typique de Docfd consiste soit à cd dans le répertoire qui vous intéresse et à lancer docfd directement, soit à spécifier les chemins comme arguments :

 docfd [PATH]...

La liste des chemins peut contenir des répertoires. Chaque répertoire de la liste est analysé récursivement pour les fichiers portant les extensions suivantes par défaut :

• Pour le mode de recherche multiligne :
  • .txt , .md , .pdf , .epub , .odt , .docx , .fb2 , .ipynb , .html , .htm
• Pour le mode de recherche sur une seule ligne :
  • .log , .csv , .tsv

Vous pouvez modifier les extensions de fichier à utiliser via --exts et --single-line-exts , ou les ajouter à la liste des extensions via --add-exts et --single-line-add-exts .

Si la liste PATH s est vide, alors Docfd analyse par défaut le répertoire actuel . sauf si l’un des éléments suivants est utilisé : --paths-from , --glob , --single-line-glob .

Documentation

Voir GitHub Wiki pour plus d'exemples/livre de recettes et de détails techniques.

Limites

• Le rechargement automatique des fichiers n'est pas pris en charge pour les fichiers PDF, car les visionneuses PDF sont appelées en arrière-plan via le shell. Il est possible de prendre en charge cela correctement de la manière indiquée ci-dessous, mais cela nécessite beaucoup d'ingénierie pour potentiellement très peu de gain :

  • Docfd attend que la visionneuse PDF se termine complètement avant de reprendre, mais cela interdit l'affichage simultané de plusieurs résultats de recherche dans différentes instances de la visionneuse PDF.

  • Docfd gère entièrement les visionneuses PDF lancées, mais ces visionneuses sont fermées à la fin de Docfd.

  • Docfd appelle les visionneuses PDF via le shell afin qu'elles restent ouvertes lorsque Docfd se termine. Docfd vérifie périodiquement s'ils sont toujours en cours d'exécution via les ID de processus des visionneuses PDF, mais cela nécessite la gestion des forks.

  • En plus de vérifier si les instances de la visionneuse PDF interagissant avec les fichiers sont toujours en cours d'exécution, Docfd doit également configurer la gestion des mises à jour des fichiers, soit via inotify , soit en vérifiant périodiquement les heures de modification des fichiers.

Reconnaissance

• Un grand merci à @lunacookies et @jthvai pour les nombreuses discussions et suggestions UI/UX
• Les gifs de démonstration et certaines captures d'écran sont réalisés en VHS.
• ripgrep-all a été utilisé comme référence pour les choix de logiciels d'extraction de texte
• Marc Coquand (auteur de Stitch) pour les discussions et l'inspiration de la fonctionnalité de réduction des résultats
• Une partie de la syntaxe de recherche a été copiée depuis fzf
• Le workflow d'édition de l'historique des commandes a été inspiré du workflow de rebase interactif Git, par exemple git rebase -i