Ghostling - émulateur de terminal Minimum Viable

• Démo de terminal aux fonctionnalités minimales basée sur la C API de libghostty, fonctionnant avec un unique fichier C et le rendu Raylib
• Conçu pour valider les capacités de libghostty-vt, le projet montre une implémentation de terminal fondée sur des graphismes 2D plutôt qu’un rendu GPU
• Prend en charge des fonctions de niveau terminal réelles comme le reflow du texte, la couleur 24 bits, la gestion de l’Unicode et les protocoles souris/clavier
• Certaines fonctions comme le Kitty Graphics Protocol et la gestion du presse-papiers et du titre via OSC ne sont pas encore implémentées, et la prise en charge de Windows n’est pas incluse
• En exploitant le cœur de libghostty, il offre une extensibilité permettant à diverses applications d’associer leur propre GUI ou moteur de rendu

---

Aperçu de Ghostling

• Ghostling est un projet de démonstration de terminal aux fonctionnalités minimales basé sur la C API de libghostty, présenté sous la forme d’un exemple composé d’un unique fichier C
• Il utilise Raylib pour la gestion de la fenêtre et le rendu, et fonctionne selon une architecture mono-thread
• Pour montrer la flexibilité de libghostty-vt, il utilise un moteur de rendu graphique 2D au lieu d’un rendu direct sur GPU
• Il ne s’agit pas d’un terminal complet pour un usage quotidien, mais d’un exemple minimal de terminal viable, avec une validation limitée de l’exactitude du code

Présentation de Libghostty

• Libghostty est une bibliothèque embarquable d’émulation de terminal extraite du cœur de Ghostty, qui fournit des API C et Zig
• libghostty-vt est une bibliothèque sans dépendances chargée de la gestion de l’état du terminal, notamment l’analyse des séquences VT, la position du curseur, les styles et le scrollback
  • Elle n’inclut ni code de rendu ni gestion de fenêtre, que l’application qui l’utilise doit implémenter elle-même
• Basée sur le code validé dans la GUI Ghostty, elle fournit une émulation de terminal précise et complète, une analyse optimisée par SIMD, une prise en charge avancée d’Unicode, une utilisation efficace de la mémoire et une stabilité issue d’une large base de tests

Fonctionnalités principales

• Prise en charge du redimensionnement de fenêtre avec reflow du texte
• Prise en charge de la couleur 24 bits et de la palette 256 couleurs, ainsi que des styles gras, italique et inversé
• Gestion de l’Unicode et des graphèmes à plusieurs code points (sans shaping ni layout)
• Gestion des touches modificatrices comme Shift, Ctrl, Alt, Super
• Prise en charge du Kitty Keyboard Protocol, du suivi de la souris (X10, normal, button, any-event) et de plusieurs formats de reporting souris (SGR, URxvt, UTF8, X10)
• Prise en charge de la molette de défilement et de la barre de défilement par glisser-déposer, ainsi que du focus reporting (CSI I / CSI O)
• Inclut la majeure partie des fonctionnalités d’émulation de terminal au même niveau que la GUI Ghostty

Fonctionnalités prévues

• Fonctionnalités pas encore entièrement exposées dans libghostty-vt

  • Kitty Graphics Protocol

  • Prise en charge du presse-papiers OSC

    • Définition du titre via OSC
    • La prise en charge de Windows est possible dans libghostty-vt, mais reste non implémentée dans Ghostling
    • La liste sera étendue à mesure que de nouvelles fonctionnalités à ajouter seront identifiées

Fonctionnalités non fournies

• libghostty se concentre sur le cœur de l’émulation de terminal et n’inclut donc pas les fonctionnalités de couche GUI
  • Onglets, fenêtres multiples, écran partagé, gestion de session, fichier de configuration, GUI, interface de recherche, etc. ne sont pas inclus
• Ces fonctionnalités doivent être implémentées directement par les applications utilisant libghostty
• Ghostling les exclut volontairement afin de conserver un exemple minimal

Méthode de build

• Prérequis : CMake 3.19 ou plus, compilateur C, Zig 0.15.x dans le PATH
• Raylib est automatiquement téléchargé via FetchContent de CMake s’il n’est pas déjà installé
• Procédure de build de base

  cmake -B build -G Ninja  
  cmake --build build  
  ./build/ghostling  
  

• Attention : les builds de debug sont très lents en raison des vérifications de sécurité, et ne conviennent pas au benchmark
• Build Release

  cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release  
  cmake --build build  
  

• Après la configuration initiale, il suffit d’exécuter cmake --build build

FAQ

• Pourquoi utiliser C au lieu de Zig

  • libghostty-vt fournit une API Zig complète, mais l’API C est plus largement utilisée et plus accessible

    • Ghostling est une démo destinée à montrer un exemple minimal d’utilisation de l’API C

• Prise en charge d’autres langages comme Rust

  • libghostty-vt peut fonctionner sans aucune dépendance via son API C
  • Il peut être utilisé dans la plupart des langages avec de simples bindings légers, et les bindings officiels sont centrés sur C et Zig
  • L’objectif est que la communauté développe et maintienne des bindings dans divers langages

• Raylib est-il obligatoire ?

  • Non. libghostty n’impose aucune contrainte sur le moteur de rendu ni le framework GUI
  • Il peut aussi fonctionner indépendamment dans un environnement WASM
  • Il fournit une API d’état de rendu, ce qui permet de l’associer à n’importe quel moteur de rendu, comme Metal, OpenGL ou Raylib

• Pourquoi avoir choisi CMake et Raylib

  • Le projet n’est lié à aucune technologie particulière, et CMake est un système de build généraliste et largement pris en charge

  • Raylib est une bibliothèque simple et facile à configurer pour les fenêtres et le rendu 2D

    • L’objectif du projet est moins le choix technique que de montrer un exemple d’utilisation de libghostty

[GN⁺]

Commentaires sur Hacker News

• J’utilise libghostty avec Trolley
  Ce projet permet de packager des TUI en applications de bureau, un peu comme lorsqu’on encapsule une web app dans Electron
  Il s’est contenté d’ajouter une interface graphique et un bundler CLI, et pourtant ça fonctionne parfaitement sous Windows
  Je suis sincèrement impressionné par les développeurs de Ghostty

  • Ce serait bien d’avoir au moins une capture d’écran dans ton README GitHub
    Ça permettrait de comprendre immédiatement quel chrome (habillage de l’interface) l’application ajoute autour du TUI

• Le fichier C était assez petit pour être lu en quelques minutes
  Vers la 5e ligne, j’ai été surpris de voir une approche originale consistant à embarquer la police via un header auto-généré
  J’étais habitué à la méthode des ressources Windows, mais ici la structure générait un tableau d’octets via du code CMake
  C’était un peu déroutant mais impressionnant — j’ai eu l’impression d’avoir enfin trouvé la solution à l’embarquement cross-platform de ressources binaires

  • Je partage ici le script de build utilisé
    Avec la commande cmake -DINPUT=pixel.gif -DOUTPUT=pixel.h -DARRAY_NAME=pixel_gif -P bin2header.cmake,
    j’ai pu convertir un GIF 1x1 pixel en tableau C
    L’image se retrouve telle quelle dans le header généré, sous forme de tableau d’octets
  • Fait amusant, les bitmaps XPM ont été conçus à l’origine pour pouvoir être #include tels quels
    La page Wikipédia sur X PixMap explique bien cette structure
  • On peut aussi générer ce genre de tableaux avec la commande xxd du package vim
    Mais c’est inefficace pour les grosses ressources — gcc/clang explosent en mémoire
    C’est pour ça que j’utilise le projet LIEF
    Il permet d’insérer puis de relire des ressources dans des binaires Windows PE, macOS Mach-O et Linux ELF
    Grâce à ça, j’ai pu construire un système de bundling de ressources cross-platform sans limite de taille
  • En tant que développeur Windows, j’ai trouvé intéressant de voir un appel à DrawTextEx
    C’était un bon exemple de la richesse d’expression de la bibliothèque Ghostty
    Les autres choix de bibliothèques étaient eux aussi excellents, et ça m’a donné envie d’essayer de créer moi-même une application de terminal
  • Je ne partage pas l’idée du “enfin trouvé”
    Inclure du binaire dans le code source est une technique ancienne
    C’était déjà courant dans les lignes DATA du BASIC des années 70–80, ainsi que dans des jeux Atari ST et Amiga
    En Java aussi, on a déjà mis des polices pixel directement dans des fichiers .java
    J’ai aussi entendu dire que certaines polices du noyau Linux étaient gérées de cette façon

• Ce projet est intéressant
  Je n’ai pas besoin de fonctions d’onglets ou de gestion de session dans un émulateur de terminal
  Le WM gère les fenêtres et les onglets, et tmux s’occupe des sessions, du scrollback, de la recherche, etc.
  Donc des terminaux simples comme urxvt, st ou foot m’ont toujours suffi
  Ghostty n’était pas vraiment à mon goût, mais celui-ci mérite d’être essayé
  La prise en charge de OSC est prévue, et ce serait bien d’ajouter un système de plugins moins contraignant que celui de st