Ma façon d’utiliser Windows Terminal – une automatisation extrême du terminal avec tmux et un workflow personnalisé

 (jyn.dev)
23 points par GN⁺ 2025-06-24 | 1 commentaires | Partager sur WhatsApp
  • En combinant tmux, SSH, nvim et de puissants scripts de recherche et d’automatisation, l’auteur a mis en place un workflow unique permettant d’explorer, modifier et rechercher instantanément des fichiers sur un serveur distant, sans GUI
  • Avec un seul raccourci clavier, il recherche automatiquement des noms de fichiers dans plusieurs fenêtres tmux et les ouvre immédiatement ; le changement de fichier et la gestion des buffers sont eux aussi entièrement pilotés au clavier
  • Frustré par la lenteur de VSCode et les conflits de raccourcis, il a unifié lui-même toutes les opérations via des scripts
  • En combinant regex, perl, tmux, nvim et d’autres outils Unix, il automatise la détection et l’ouverture de chemins de fichiers et d’informations de ligne
  • Même si l’implémentation est très complexe, cela montre jusqu’où l’on peut pousser la puissance et l’extensibilité du terminal

Ma façon d’utiliser le terminal

  • Cet article partage une expérience de construction d’un environnement de développement efficace en combinant le terminal et divers outils
  • Comme le processus est complexe et se prête normalement mieux à la vidéo, l’article s’appuie sur du texte accompagné de vidéos de démonstration (visionnage indispensable)
  • Certains passages de la vidéo (0:11, 0:21, 0:41) sont les moments où beaucoup se demandent : « C’est vraiment possible ? »

Résumé étape par étape du workflow terminal montré dans la vidéo

  • 0:00 : Lancement de Windows Terminal sur un ordinateur portable
  • 0:02 : ouverture d’un nouvel onglet terminal avec le raccourci ctrl + shift + 5, connexion au desktop de la maison via ssh, puis lancement immédiat de tmux
  • 0:03 : exécution du shell par défaut zsh dans tmux, affichage du prompt et chargement asynchrone de toute la configuration
  • 0:08 : utilisation de zoxide pour faire une recherche fuzzy parmi les répertoires récents puis s’y déplacer
  • 0:09 : début de saisie d’une commande ripgrep, autocomplétée par zsh à partir de l’historique d’utilisation, puis acceptée avec ctrl + f
  • 0:11 : avec le raccourci ctrl + kf, recherche de noms de fichiers dans tout le scrollback de tmux ; les noms de fichiers sont surlignés en bleu
  • 0:12 : appui répété sur la touche n pour parcourir la liste des fichiers trouvés jusqu’à celui voulu
  • 0:21 : avec la touche o, ouverture du fichier sélectionné dans l’application par défaut (nvim) ; tmux l’exécute dans une nouvelle fenêtre (toujours sur le serveur distant)
  • 0:26 : tentative de navigation entre plusieurs références dans le code avec rust-analyzer ; certains macros ne sont pas reconnus, puis le déplacement fonctionne correctement à 0:32
  • 0:38 : avec ctrl + kh, bascule du focus tmux vers la fenêtre de gauche
  • 0:39 : nouvel appui sur n pour continuer à parcourir les résultats de recherche précédents en état « copy-mode »
  • 0:41 : avec la touche o, ouverture cette fois d’un autre fichier dans l’instance nvim déjà ouverte
  • 0:43 : avec la touche b, affichage de la liste des buffers de fichiers ouverts, puis alternance entre les deux fichiers pour finir

Pourquoi utiliser un tel workflow terminal ?

  • VSCode est lent, surtout avec le plugin vim, où tout devient très poussif
    • Des conflits de raccourcis surviennent souvent entre l’éditeur, le plugin vim, le terminal et les fonctions de gestion des fenêtres, ce qui le rend inconfortable à utiliser
    • L’auteur a aussi essayé l’éditeur Zed, mais à l’époque il était encore immature et le problème des conflits de raccourcis persistait
  • Il a alors commencé à utiliser directement nvim (Neovim) dans le terminal, mais
    • le fait de copier-coller manuellement dans l’éditeur les noms de fichiers trouvés avec ripgrep était beaucoup trop fastidieux
    • surtout lorsque les résultats de ripgrep incluent à la fois le nom du fichier et le numéro de ligne,
      • cela provoquait des erreurs de syntaxe à chaque collage
      • et obligeait souvent à faire des modifications inutiles avant même d’ouvrir réellement le fichier
    • il ressentait donc le besoin d’un workflow capable d’ouvrir directement un chemin de fichier, comme le ctrl-click de VSCode
  • C’est pourquoi il a implémenté lui-même les fonctions voulues avec tmux
    • quand on lui demande pourquoi il utilise tmux, il répond que c’est précisément pour cette automatisation et pour la persistance des sessions
    • le terminal est bien plus puissant qu’on ne l’imagine, mais ces possibilités d’automatisation ne sont pas visibles avec les seules fonctions de base
    • même si tmux est ancien, sa syntaxe complexe et parfois boguée, il l’a choisi pour son extensibilité et ses possibilités de personnalisation

Principales méthodes d’implémentation

Recherche de noms de fichiers dans tout le scrollback de tmux

  • Dans le copy-mode de tmux, appariement de motifs de noms de fichiers via des expressions régulières complexes
  • Un script regex maison (search-regex.sh) surligne les chemins de fichiers, les lignes et même les colonnes
  • Exemple de configuration tmux : 
    bind-key f copy-mode \; send-keys -X search-backward '정규표현식'

Ouvrir le fichier sélectionné dans une nouvelle fenêtre ou la fenêtre courante

  • Avec des raccourcis tmux personnalisés, le fichier sélectionné s’ouvre dans l’application par défaut ou dans l’éditeur (nvim, etc.)
  • Prise en charge des chemins relatifs et de l’expansion du tilde 
    bind-key -T copy-mode-vi o  send-keys -X copy-pipe 'cd #{pane_current_path}; ...'  
bind-key -T copy-mode-vi O  send-keys -X copy-pipe-and-cancel 'tmux send-keys ...'

Ouvrir un fichier dans une instance nvim déjà ouverte

  • Un script perl permet à tmux de retrouver un pane nvim spécifique, puis d’y envoyer directement les frappes contenant le fichier et même les informations de ligne
  • La syntaxe file:line:column est convertie en commande vim pour une ouverture automatique

Avantages et limites de cette approche

  • Dépassement des limites fonctionnelles du terminal local : exploration, modification et recherche de fichiers librement sur un serveur distant grâce à tmux
  • Même si l’éditeur ne prend pas en charge un protocole d’édition distante, le même workflow reste possible
  • Tous les raccourcis, la recherche, le changement de fichier, la gestion des buffers, etc. sont intégrés exactement selon ses préférences
  • Automatisation plus rapide et plus simple à mettre en place que la création d’un plugin VSCode
  • Les scripts maison sont fragiles et difficiles à maintenir, donc difficiles à recommander à d’autres

Solutions alternatives

  • Combinaisons open source / outils généralement recommandés :
    • fish + zoxide + fzf : peut remplacer les workflows de recherche fuzzy de répertoires, de commandes et une partie de la recherche de fichiers
    • les fonctions intégrées de l’éditeur (onglets, fenêtres, fuzzy finder, etc.) suffisent à la plupart des utilisateurs
    • qf : permet de sélectionner des fichiers depuis la sortie du terminal, mais ne peut pas s’intégrer à des outils interactifs et utilise une CLI de style vi
    • e : petit outil capable de reconnaître les chemins file:line (avec besoin de scripts distincts selon le type d’éditeur)
    • vim --remote, code filename, emacsclient, etc. offrent un effet similaire, mais la reconnaissance de file:line reste incomplète

Conclusion et enseignements

  • Le terminal est bien plus puissant qu’on ne le pense ; en combinant soi-même des scripts, on peut obtenir des automatisations impossibles avec des outils GUI
  • Mais il existe des limites pratiques, notamment en termes de maintenabilité et de bugs inhérents aux scripts
  • Si l’automatisation des workflows terminal vous intéresse, il est plus réaliste de construire progressivement un environnement personnalisé autour de tmux/nvim/fzf

À lire aussi

1 commentaires

 
GN⁺ 2025-06-24
Avis Hacker News

  • J’utilise aussi un truc similaire. J’exploite le scrollback de tmux et j’envoie la sortie tokenisée vers zsh, ce qui me permet d’utiliser l’autocomplétion sur tout ce qui est visible à l’écran dans tmux. Je partage un post Threads connexe et le code gist. Ça m’a été vraiment très utile

  • J’aime beaucoup ce type de workflow, et j’affine quelque chose de similaire depuis des années, par itérations. Avec le temps, j’essaie de réduire au maximum les couches custom, parce que plus on ajoute d’overlays, plus le coût de maintenance augmente. On peut faire la plupart des choses présentées dans le billet avec Vim vanilla (sans tmux séparé), par exemple avec rg --vimgrep restore_tool | vim -c cb - (vim -c cb - est l’une de mes fonctionnalités préférées dans Vim, et je trouve presque étonnant que si peu de gens l’utilisent). Bien sûr, relancer la recherche rg à chaque fois peut coûter cher, donc j’analyse souvent les résultats dans le terminal puis, si besoin, j’utilise une commande tmux custom pour copier la sortie de la dernière commande et l’envoyer vers vim. Pour ça, j’utilise parfois l’astuce consistant à exploiter des caractères Unicode dans le prompt, ou je passe par tmux saveb - | vim -c cb -

    • Il y a 10 ans, j’ai abandonné une énorme configuration vim multi-fichiers et multi-packages, et depuis je simplifie progressivement en ne gardant qu’un vimrc très simple, auquel j’ajoute environ 1 à 2 lignes par an. Les réglages par défaut des vieux logiciels ont généralement une raison d’être ; au lieu de les changer à l’aveugle, je recommande de commencer par comprendre cette raison
    • (Tu dis que vim -c cb - est ta fonctionnalité préférée dans Vim ; est-ce que tu pourrais expliquer ce que ça fait ? Même en testant ls | vim - et ls | vim -c cb -, je ne vois pas tout de suite la différence)
    • Je me demande si c’est destiné au même usage que vim -q <(ripgrep --vimgrep restore_tool)

  • Ce setup est agréable à voir, avec tmux, fzf, rg, zoxide, et un nvim bien propre. S’ils n’y sont pas, j’aimerais aussi recommander atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust, btop, etc. On trouve tout ça dans les listes Awesome Terminal XYZ sur GitHub. atuin est quasiment indispensable, et sans zoxide, c’est comme être un athlète avec des chaussures mal ajustées. Pour enregistrer des vidéos de terminal, asciinema est un meilleur choix. En réalité, autrefois, ce genre de setup s’appelait simplement « être programmeur ». Aujourd’hui, il faut aussi maîtriser des outils comme VSCode, Zed, Cursor, et savoir à quel LLM confier quoi. Ces outils ne sont plus que le nouveau « minimum », et ne remplacent pas l’environnement existant. Même si on utilise très bien Claude Code ou gptel, parfois ils peuvent casser l’arborescence, et je n’imagine pas utiliser git sans magit. Si quelqu’un pense qu’avec Cursor vanilla il va plus vite que l’OP, qu’il montre une vidéo de lui en train d’utiliser un LLM en conditions réelles

    • Être programmeur, ce n’est pas seulement configurer son environnement de développement. Certains programmeurs réputés utilisent volontiers l’éditeur ex, alors que certains débutants ont un IDE très clinquant mais manquent de compréhension fondamentale. Bien sûr, de bons outils peuvent aider, mais leur impact réel sur la réussite a généralement été faible. Les LLM changeront peut-être cela. Par exemple, même si de mauvaises chaussures de course vous ralentissent de 5 %, dans une startup, ce n’est pas ce genre de détail qui fait la différence entre succès et échec. Les causes sont le plus souvent des problèmes plus importants, comme des conflits entre cofondateurs, une perte de motivation ou un mauvais product-market fit
    • Ta liste d’outils est bonne, mais pour quelqu’un qui ne connaît pas la plupart de ces noms — atuin, dogdns, btop, etc. — ça peut quand même sembler assez obscur
    • J’adore cette liste de commandes. J’y ajouterais absolument fd (par sharkdp). C’est un remplaçant de find, excellent du point de vue de l’ergonomie. Et atuin est la plus grosse amélioration de ma vie en CLI. Il me permet de retrouver très facilement des commandes rares que j’ai tapées il y a 6 mois
    • On dirait que tu accordes trop d’importance au choix des outils. Les très bons développeurs sortent rapidement quelque chose de valable même dans un environnement nu. Bien sûr, de bons outils peuvent aider un peu à la marge, mais pour la plupart d’entre nous, c’est surtout une question de plaisir personnel et de préférence. Si tu as vraiment l’impression que ta productivité dépend énormément de ton IDE, cela veut probablement dire que tu as encore un long chemin d’apprentissage et de progression devant toi. Depuis toujours, « connaître les outils = être programmeur » n’a jamais été une formule valable. Les meilleurs développeurs que j’ai vus obtenaient des résultats impressionnants avec essentiellement more/grep/vi et beaucoup de réflexion. La création de valeur vient au final de la pensée. Même à l’ère des LLM, cela reste vrai

  • Tous les utilisateurs de vim/tmux ont probablement fabriqué à moitié leur propre « imitation d’Emacs » non officielle, un peu buggée mais rapide

    • J’ai même créé un émulateur de terminal qui remplace le préfixe tmux à deux touches par une seule touche modifiée avec Ctrl pour toutes les commandes. Lien du projet
    • J’utilise à la fois vim/tmux et emacs (et avant ça, j’ai longtemps utilisé uniquement emacs), et mon environnement emacs était bien plus improvisé, moins documenté et plus buggé. Le setup vim+tmux est relativement plus stable
    • Je ressens ça très fortement. Dans mon workflow actuel, je lance :Term à l’intérieur de nvim
    • L’environnement vim+tmux repose beaucoup sur des primitives système comme les pipes, les fichiers, les signaux et le scrollback. Du coup, l’outillage fonctionne de manière naturelle et transparente dans des environnements variés, via ssh, ou même avec des shells limités. C’est un gros avantage pour la portabilité et le débogage. Autrement dit, j’ai l’impression que mon workflow se fragmente librement sur la base de ces garanties fondamentales, donc construire moi-même ma config vim me semble être un choix parfaitement naturel

  • Il dit qu’il utilise tmux sur Windows, mais je me demande concrètement comment. Si quelqu’un peut l’expliquer, ce serait bien

    • À mon avis, il se connecte à distance à un système Unix pour faire le vrai travail. On peut faire tourner tmux parfaitement sur un serveur Unix. Moi aussi, il m’arrive de me connecter en SSH à une VM VirtualBox pour avoir une couche de compatibilité plus propre que WSL. C’est aussi l’une des raisons pour lesquelles tmux est plus puissant que d’autres approches. Tant qu’il est installé sur le serveur, il remplit aussi parfaitement son rôle à distance. Lien explicatif connexe

  • J’aime beaucoup cette manière de partager un workflow. C’est parfaitement adapté au public visé. J’aurais aimé que la vidéo ait du son, mais lire la liste des actions après coup allait aussi. J’y ai trouvé des idées utiles pour mon propre workflow. Il a mentionné les raccourcis clavier ésotériques de tmux ; est-ce que quelqu’un ici a déjà utilisé byobu ? byobu est un wrapper autour de tmux qui assigne la plupart des commandes aux touches F#. Je l’ai découvert il y a 10 ans et je l’utilise depuis sans interruption. Avant ça, j’ai utilisé tmux pur pendant quelques années

    • Ravi que le contenu t’ait plu :) J’ai essayé de le rendre aussi clair que possible et facile à parcourir d’un coup d’œil. J’ai remappé la plupart de mes raccourcis tmux. ctrl-k sert de préfixe, et h n’est pas la valeur par défaut pour « sélectionner le panneau de gauche ». Je n’ai jamais utilisé byobu, mais d’après ce que tu en dis, ça ressemble surtout à des raccourcis par défaut un peu plus pratiques, donc je n’ai pas spécialement envie d’ajouter encore une couche

  • On peut aussi étendre des fonctions comme le mode copie avec des plugins tmux, sans avoir à écrire soi-même une énorme regex. Il y a par exemple tmux-fpp, tmux-copycat, tmux-fingers, tmux-urlview. À noter que s’appuyer au maximum sur les fonctions intégrées peut être meilleur pour les performances. J’aime aussi beaucoup tmux-resurrect (sauvegarde/restauration de session), tmux-continuum (automatisation) et tmux-zen pour Oh-My-Fish. Voici tmux-resurrect, tmux-continuum, tmux-zen. Je veux insister sur le fait qu’un bel environnement tmux est vraiment plus facile à mettre en place qu’on ne le pense

    • J’ai moi aussi repris la regex d’origine de tmux-copycat. Mais a) cette regex gère mal :, et b) copycat utilise sa propre abstraction de visualisation, donc on ne peut faire qu’une seule action par recherche. Ma méthode réutilise la recherche intégrée de tmux, ce qui me permet d’associer librement l’action de mon choix aux fichiers mis en évidence. Si la plupart des plugins se limitent au copier-coller ou ajoutent leur propre mode, c’est aussi parce que tmux ne permet pratiquement de contrôler la surbrillance qu’à travers sa recherche intégrée

  • Ce setup est vraiment magnifique. En revanche, c’est un mystère qu’un vrai typeahead IA n’ait pas encore débarqué dans le terminal. Cursor Tab semblerait parfait pour ça, mais son application au terminal est bloquée. J’ai presque envie de bricoler un produit temporaire qui enverrait la sortie du terminal vers Cursor via un faux fichier

  • Le titre de l’article est en réalité « How I use my terminal »

    • La fonctionnalité automatique de HN coupe le premier mot du titre quand c’est How. Il n’y a pas vraiment de base solide à ça ; les admins disent que c’est pour éviter le clickbait, mais en pratique ça ne fait qu’ajouter de la confusion
    • Au début, j’ai cru que cet article était une parodie de « There Will Be Blood » (vu que le titre actuel est « I use my terminal »)
    • Moi aussi, j’ai cru qu’il s’agissait du retour d’expérience de quelqu’un sur un émulateur de terminal qu’il aurait lui-même créé
    • Moi aussi, je viens de le découvrir. En parcourant le texte, je dirais que le titre complet est plutôt quelque chose comme « I use my terminal (and so should you) ». Les articles sur le terminal sont toujours les bienvenus, et en tant qu’utilisateur de Chromebook, un navigateur et un terminal m’ont toujours suffi. Quand je passe sur Mac, c’est bien trop dispersé, donc au quotidien je n’utilise en général que le terminal ou le navigateur
    • Lors de l’enregistrement d’un titre sur HN, les préfixes ou suffixes trop courants sont souvent coupés automatiquement