Le terminal est le dernier outil qu'on repense

Tous les quelques années, l'éditeur est refait, le navigateur est refait, la chaîne de compilation est refaite, et le terminal reste là où il a toujours été : la plus vieille fenêtre de l'écran, ouverte à la première connexion et guère remise en question depuis. Ce n'est pas faute d'avoir quelque chose à réparer. C'est que le tampon de texte qui défile ligne à ligne est devenu si évident que presque plus personne ne le voit comme une décision de conception, et que tout le monde le prend pour la forme qu'un terminal possède par nature. Le contre-pied part de l'autre côté de cette évidence : le tampon est un choix, il a été fait il y a des décennies pour des machines qui n'existent plus, et il peut donc être refait.

Une commande, un bloc, tenus ensemble

La première différence est structurelle, pas cosmétique. Au lieu d'un flux unique où les commandes et les résultats s'entremêlent en un mur de texte, chaque commande et la sortie qu'elle a produite restent réunis dans un même bloc. Un bloc se replie en une ligne, se copie en entier, se relance seul, et remonter dans une session devient un saut d'un bloc à l'autre plutôt qu'un défilement à l'aveugle où l'on scrute les caractères d'invite pour deviner où une chose s'est arrêtée et où la suivante a commencé. Quiconque a passé dix minutes à remonter un journal de compilation bruyant pour trouver la ligne où l'échec a commencé sait ce que cela vaut, et sait aussi que la réponse n'est pas une plus jolie police.

Une complétion qui lit la ligne, pas seulement le début

La complétion d'un shell classique compare un début de mot à une liste de noms. Elle sait ce qui existe, pas ce qu'on cherche à faire. Ici la suggestion vient du contexte de la ligne entière, si bien qu'une commande à moitié tapée peut être achevée dans la forme qui convient aux arguments déjà donnés, et qu'une commande inconnue peut être expliquée et pas seulement allongée. Le gain est le plus net pour ceux qui apprennent encore un environnement : l'écart entre savoir qu'un outil existe et savoir comment l'appeler cesse de coûter une recherche dans la documentation à chaque fois. La recherche dans l'historique fonctionne de la même manière, par mots clés à travers les sessions passées, plutôt qu'en pressant quarante fois une flèche.

Modifier la commande comme du code

Taper derrière une invite classique est une affaire d'une seule ligne : le curseur reste à la fin, et tout ce qu'il faut changer demande de revenir en arrière. Ici la ligne de commande est un champ de texte avec un éditeur derrière, donc la sélection, les curseurs multiples et les combinaisons de touches habituelles agissent sur ce qui est déjà écrit. Pour qui passe la journée dans un éditeur de code moderne, cela retire une friction petite mais constante, parce que les mains n'ont plus à passer de l'une à l'autre de deux séries d'habitudes selon la fenêtre qui a le focus. Les résultats sont traités de la même façon : une sortie longue s'inspecte et se travaille dans le bloc, au lieu d'être d'abord copiée ailleurs.

Des commandes que l'équipe peut conserver

C'est la partie qui porte le plus loin. Les commandes fréquentes, les petits scripts et des procédures entières peuvent être enregistrés comme des éléments nommés et partageables, puis circuler dans une équipe, de sorte qu'une séquence qui fonctionne est écrite une fois et réutilisée au lieu d'être reconstituée de mémoire par chaque personne qui en a besoin. La conséquence réelle n'est pas la commodité mais la mémoire : un terminal qui retient ce qu'une équipe a appris cesse d'être purement personnel, et le savoir qui vit d'ordinaire dans l'historique du shell d'une seule personne devient la propriété du groupe. L'arrivée d'un nouveau collègue ne ressemble plus à la même chose quand les procédures courantes sont déjà là, écrites noir sur blanc, à l'endroit où elles seront réellement exécutées.

Du Rust en dessous, et un GPU qui dessine le texte

Deux choix de mise en œuvre expliquent une bonne part de la sensation. L'application est écrite en Rust, un langage retenu dans toute l'industrie pour sa vitesse et sa sûreté mémoire, ce qui compte ici parce que le métier d'un terminal est de rester réactif pendant que quelque chose d'autre le submerge de sortie. L'interface est dessinée par le GPU, donc le défilement, le redessin et la mise en page de contenus denses reviennent à du matériel conçu pour cela, au contraire des terminaux qui demandent au processeur de repeindre l'écran. Dans une session calme, la différence est invisible. Elle devient manifeste à l'instant où une suite de tests débite des milliers de lignes ou qu'un journal est ouvert sans filtre et que l'image doit suivre.

Ce qu'il exige encore de vous

Rien de tout cela ne vient sans contrepartie. La couverture des plateformes est plus étroite que celle d'un terminal livré avec chaque Unix depuis des décennies : macOS et Linux sont le terrain pris en charge, et ceux qui travaillent d'un système à l'autre devraient vérifier avant de déplacer ici leurs habitudes quotidiennes. Les environnements de shell très personnalisés sont le second endroit où la friction apparaît, car une configuration bâtie pendant des années autour d'un cadre d'invite particulier ne suivra peut-être pas telle quelle. Le troisième coût est le moins visible et le plus réel : le modèle d'interaction est assez différent pour que les utilisateurs de longue date aient besoin de quelques jours avant que leurs doigts cessent de chercher des habitudes qui ne s'appliquent plus. C'est étrange de l'inscrire parmi les défauts, mais prétendre le contraire serait malhonnête.

Le compromis en vaut-il la peine

Un terminal sert plus souvent que presque tout le reste sur la machine d'un développeur et se repense moins souvent que tout le reste, et c'est précisément cette combinaison qui rend une refonte digne d'être examinée pour ses propres raisons plutôt que renvoyée au rang de décoration. Des blocs structurés, une complétion qui tient compte du contexte, un traitement du texte de niveau éditeur et un dépôt partagé de procédures d'équipe règlent chacun un problème que l'on résout aujourd'hui en faisant défiler, en cherchant dans la documentation ou en interrogeant celui qui a écrit le script. Qui vit entièrement dans un shell familier et une poignée de commandes y gagnera peu et risque de trouver pénible de réapprendre les gestes. Qui lit de longues sorties, partage les mêmes procédures avec d'autres ou apprend encore la ligne de commande remarquera la différence dès le premier après-midi. Le résumé honnête : ce n'est pas une meilleure version du terminal que tout le monde possède déjà, c'est l'idée qu'un nouveau était dû, et cette idée est assez solide pour être mise à l'épreuve d'une semaine de votre travail.