Un outillage sur mesure
Comme je l’ai mentionné dans un billet précédent, L’IA, le retour des outils sur mesure à usage unique, je pense que l’IA nous aide à revenir à un outillage taillé pour nous.
Cela dit, je ne pense pas être le seul à avoir ce goût particulier, alors j’ai fabriqué un ensemble d’outils qui collent à mon quotidien et j’ai décidé de les partager.
Mon travail quotidien se passe sous macOS, j’ai donc fait ces outils pour cette plateforme d’abord. Je pratique beaucoup le dogfooding, alors j’ai laissé Claude travailler en arrière-plan et j’ai simplement fait une relecture et une amélioration rapides après chaque fonctionnalité terminée, en continuant à alimenter des tickets au fur et à mesure que je tombais sur des aspérités.
J’ai repris de GhosTTY l’idée d’un cœur dans un langage solide et d’une interface en natif, et ça a fonctionné jusqu’ici.
Les interfaces macOS sont faites en SwiftUI+AppKit et celles de Linux en GTK+LibAdwaita ; je teste ces dernières sur une VM puisque ma machine Linux est actuellement dans mon garage, câblée à des expériences matérielles.
J’ai fait jusqu’ici deux outils que j’utilise régulièrement et j’en ferai d’autres à mesure que je rencontrerai d’autres points de friction. Je me suis laissé influencer par ce billet à propos des TUIs et je suis plutôt d’accord avec lui, mais uniquement dans le statu quo actuel où les abstractions d’interface peuvent finir par être plus que ce qui est exprimable dans un terminal et où faire plusieurs frontends natifs coûte peu en heures humaines.
Les outils
Je produis des paquets deb, rpm, nix et arch ainsi que des applications macOS signées (j’ai payé un an de ce compte développeur Apple, alors autant en tirer quelque chose)
TextChum
TextChum, dont le code se trouve ici.
A commencé comme une implémentation moderne d’un éditeur à la TextMate (si ça vous convient, achetez TextMate et soutenez son auteur ; son éditeur a été pendant des années la référence absolue de l’élégance minimaliste, je ne suis pas parvenu à ce niveau et je n’y parviendrai pas)
Un peu plus qu’un éditeur mais certainement moins qu’un IDE.
Les fonctionnalités sont très taillées pour ma façon d’éditer des fichiers :
- Les VSplits sont des colonnes, chaque panneau peut afficher un fichier différent ou tous le même
- Les HSplits sont simplement des divisions sur le fichier de cette colonne.
- Des LSP pour les langages, mais l’IDE-isme s’arrête là.
- Des formateurs à la sauvegarde.
- Beaucoup de micro-comportements configurables.
- Un aperçu pour le Markdown (et un aperçu plutôt digne pour le Markdown de Hugo, comme celui de ce billet)
- i18n inclus pour en, fr et es (n’hésitez pas à en ajouter d’autres)
- La possibilité de détacher des onglets dans d’autres fenêtres ou des « projets » dans des fenêtres.
- Une ligne de commande
chumpour pouvoir l’utiliser comme$EDITOR - Plusieurs autres micro-conforts, n’hésitez pas à tester et à donner votre avis
PRChum
PRChum, dont le code se trouve ici.
C’est un outil plus simple, à la base une sorte de pager git.
Il vous donne un plugin git pour que vous puissiez invoquer git prchum et éviter ainsi d’essayer de remplacer le pager pour finir par échouer à un moment.
En principe il permet de naviguer dans les diffs mais aussi de relire des PR depuis une forge (il prend surtout en charge GitHub et Forgejo).
Il a aussi une manière de s’utiliser en boucle avec un harnais LLM comme opencode, afin de donner et recevoir du retour pendant le travail.
Enfin, il y a quelques commodités comme des listes de PR à partir de celles ouvertes précédemment et un écran « ouvrir une PR » qui accepte des requêtes de recherche de la forge à enregistrer.