Ghostel.el - émulateur de terminal Emacs basé sur libghostty

 (dakra.github.io)
1 points par GN⁺ 4 시간 전 | 3 commentaires | Partager sur WhatsApp
  • Ghostel est un émulateur de terminal pour Emacs qui utilise le même moteur libghostty-vt que Ghostty ; un module natif Zig gère l’état du terminal, le rendu et les entrées/sorties PTY locales, tandis qu’Elisp s’occupe des raccourcis clavier, des buffers, des commandes et des processus distants
  • Il prend en charge les protocoles clavier et graphique de Kitty, les hyperliens OSC 8, les requêtes de couleur OSC 4/10/11, la sortie synchronisée DEC 2026 et cinq modes de saisie, et applique automatiquement l’intégration shell à bash, zsh, fish et nushell en local
  • Il prend en charge Emacs 28.1 ou version ultérieure ainsi que macOS, Linux, FreeBSD et Windows natif, et peut télécharger automatiquement des modules précompilés selon la plateforme lors de la première utilisation ; une toolchain Zig n’est donc pas nécessaire pour une installation classique
  • Dans un benchmark sur Apple M4 Max et Emacs 32.0.50 traitant une sortie de 1 Mo, Ghostel atteint 75 Mo/s en ASCII standard, contre 18 Mo/s pour vterm et 6,2 Mo/s pour eat ; le PTY natif absorbe une tâche cat de 10 Mo en environ 110 ms
  • Il propose aussi un terminal distant via TRAMP, la protection de la saisie des mots de passe, les images inline Kitty, ainsi que l’intégration avec compilation, Eshell, Comint, Evil et les méthodes de saisie, mais les cibles distantes et le traitement des images restent soumis à des contraintes de plateforme et de protocole

Architecture et installation

  • Ghostel s’inspire de l’architecture en deux couches de emacs-libvterm, mais utilise le moteur VT moderne de Ghostty à la place de libvterm
    • Le module Zig gère l’état du terminal, le rendu, l’encodage des touches, le PTY local et la lecture en arrière-plan
    • Elisp prend en charge les raccourcis clavier, les buffers, les commandes, l’intégration aux projets et les processus distants TRAMP
  • Les prérequis sont Emacs 28.1 ou supérieur avec prise en charge des modules dynamiques, ainsi que macOS, Linux, FreeBSD ou Windows natif
    • Des binaires précompilés sont fournis pour aarch64-macos, x86_64-macos, x86_64-linux, aarch64-linux, x86_64-freebsd, x86_64-windows et aarch64-windows
    • Pour les autres plateformes ou une compilation depuis les sources, Zig 0.15.2 est requis
  • L’installation peut se faire via MELPA, use-package :vc d’Emacs 30 ou version ultérieure, :load-path, ou un require manuel, puis le terminal s’ouvre avec M-x ghostel
  • Si le module natif est absent, Ghostel propose soit un téléchargement soit une compilation depuis les sources selon le réglage ghostel-module-auto-install
    • M-x ghostel-download-module récupère le binaire minimal pris en charge, et avec un argument préfixe permet de choisir un tag de release
    • M-x ghostel-module-compile compile le module avec zig build
    • Si le répertoire du package risque d’être réinstallé, ghostel-module-directory peut pointer vers un emplacement séparé
  • La compilation depuis les sources inclut le fichier généré vendor/emacs-module.h, ce qui évite en général d’avoir besoin des en-têtes Emacs locaux, et EMACS_INCLUDE_DIR ou EMACS_BIN_DIR permettent de changer l’emplacement des en-têtes
    • Le terminfo compilé xterm-ghostty est inclus dans etc/terminfo/ dans un format portable entre BSD et ncurses

Prise en charge de Windows

  • Sous Emacs natif pour Windows, les terminaux locaux s’exécutent via ConPTY, et l’architecture de la DLL du module doit correspondre à celle d’Emacs, pas à celle de Windows
  • Avec les modules précompilés, les fichiers de support conpty.dll et OpenConsole.exe sont également téléchargés ; s’ils sont absents, l’API ConPTY intégrée à Windows est utilisée à la place
  • Les builds Emacs personnalisés particuliers, comme ceux avec CRT statique, ne sont pris en charge qu’au mieux
  • Le terminal TRAMP sous Windows ne prend en charge que des cibles distantes POSIX, le PTY se trouvant sur l’hôte distant, et le redimensionnement dynamique de la fenêtre n’est pas encore pris en charge

Cinq modes de saisie

  • Le mode semi-char par défaut envoie la plupart des touches au terminal, mais laisse à Emacs certaines exceptions comme C-c, C-x, C-u, C-h, M-x, M-: et C-\
    • Il fournit des touches pour envoyer interruption, suspension et EOF, pour le bracketed paste, l’effacement du scrollback, ainsi que le déplacement entre invites et hyperliens
  • Le mode char envoie toutes les touches au terminal ; il convient donc aux TUI qui utilisent elles-mêmes C-x, M-x et C-h, avec seulement M-RET conservé comme touche d’échappement
  • Le mode Emacs continue de recevoir la sortie du terminal tout en passant le buffer en lecture seule, afin de permettre la navigation standard d’Emacs comme isearch, occur, les marques et la copie
    • La saisie normale n’est pas transmise au shell, et seul un collage volontaire via C-y est envoyé sous forme de bracketed paste
  • Le mode copy suspend l’actualisation du terminal pour permettre une sélection, une navigation et une copie stables
    • Dans le texte copié, les retours à la ligne dus au soft wrap sont supprimés
    • Avec le réglage par défaut ghostel-readonly-fast-exit=t, une saisie de caractère ou une copie ramène automatiquement à la session de terminal normale
  • Le mode line n’envoie pas immédiatement les touches au shell : on édite une ligne dans un buffer Emacs, puis elle est transmise d’un bloc à RET
    • Même si une sortie asynchrone ou une nouvelle invite arrive, la saisie en cours est conservée sous forme d’instantané puis réinsérée
    • Si OSC 133 est disponible, les limites d’invite sont utilisées ; sinon, elles sont repérées avec ghostel-prompt-regexp
    • Lorsqu’un TUI plein écran démarre, Ghostel bascule en mode semi-char puis revient en mode line à la fermeture du TUI
    • TAB utilise la complétion comint et, en option, la programmable completion de bash
  • Par défaut, un glisser de souris, plusieurs clics, l’activation de la marque, ou le fait que isearch ou consult-line fasse sortir de la position de saisie active déclenche le passage en mode copy afin de préserver la sélection et la position
    • Si un TUI a activé le suivi de souris DEC, les événements souris sont transmis au programme concerné en mode saisie
    • ghostel-mouse-drag-input-mode, ghostel-mark-activation-input-mode et ghostel-point-leave-input-mode permettent de modifier ce comportement

Fonctions du terminal et rendu

  • Via libghostty-vt, Ghostel prend en charge une émulation VT complète, les couleurs 256 et 24 bits, l’alternate screen, plusieurs styles et couleurs de soulignement, le gras, l’italique, le faible contraste, le barré et l’inversion, ainsi que quatre formes de curseur et leur clignotement
  • Le TERM=xterm-ghostty par défaut et le terminfo fourni annoncent aux applications des fonctions comme la sortie synchronisée DEC 2026, le clavier Kitty, les true colors, le soulignement coloré et le signalement du focus
    • Grâce aux requêtes OSC 4/10/11, les TUI peuvent obtenir la palette ainsi que les couleurs de premier plan et d’arrière-plan à partir des faces Emacs
    • Le presse-papiers OSC 52 est pris en charge, mais désactivé par défaut ; le terminfo fourni n’annonce donc pas la capacité Ms
  • Le scrollback par défaut est de 5 Mo, soit environ 5 000 lignes, et comme il est matérialisé dans un buffer Emacs, il peut être recherché avec isearch et consult-line
  • En plus des hyperliens OSC 8, Ghostel détecte les URL HTTP et HTTPS ordinaires ainsi que les chemins de fichier au format /path/file.el:42 pour en faire des liens cliquables
  • Il prend en charge l’encodeur de touches Ghostty, le protocole clavier de Kitty, les événements souris SGR, les événements de focus DEC 1004, ainsi que le glisser-déposer de chemins de fichiers et de texte
  • Le moteur de rendu ignore les lignes inchangées, regroupe les mises à jour via un timer et ajuste le framerate de manière adaptative
    • Les échos PTY arrivant juste après une frappe contournent le timer par défaut de 33 ms pour être rendus immédiatement
    • ghostel-sync-theme resynchronise la palette avec le thème Emacs
  • Les 16 couleurs ANSI sont des faces Emacs héritant de term-color-*, et ghostel-default permet de définir une police, une taille, une couleur de premier plan et une couleur d’arrière-plan propres au terminal

Intégration shell et appel d’Emacs

  • Pour bash, zsh, fish et nushell, le suivi de répertoire OSC 7, le déplacement d’invite OSC 133, le suivi du titre OSC 2 et ghostel_cmd sont configurés automatiquement
    • L’intégration shell propre à nushell fournit OSC 7, 133 et 2, et ghostel.nu ajoute ghostel_cmd ainsi qu’un wrapper terminfo SSH sortant
    • Le bash 3.2 intégré à macOS ignore ENV, utilisé pour l’injection automatique ; il faut donc utiliser un bash récent ou charger ghostel.bash manuellement
  • ghostel_cmd, qui appelle Elisp depuis le shell, utilise une extension OSC 52;e dédiée et n’exécute que les fonctions présentes dans la liste d’autorisation ghostel-eval-cmds
    • Les fonctions autorisées par défaut sont find-file, find-file-other-window, dired, dired-other-window et message
  • Les signets Emacs enregistrent le répertoire de travail du terminal et le nom du buffer
    • Si un buffer existant est présent, il est réutilisé ; sinon, un nouveau shell est lancé dans le répertoire enregistré
    • Le scrollback et le contenu de la session ne sont pas enregistrés

Mot de passe, presse-papiers et notifications

  • Lorsqu’une invite de mot de passe comme sudo, ssh, gpg ou passwd est détectée, read-passwd s’ouvre et la réponse est envoyée directement au PTY, de sorte que la saisie ne reste ni dans view-lossage, ni dans l’anneau des touches récentes, ni dans une macro clavier
    • En local, la désactivation du mode canonique et de l’écho est vérifiée via tcgetattr
    • Sur shell distant uniquement, une détection de remplacement par expression régulière est utilisée afin de réduire les faux positifs dans les TUI locales en raw mode
    • Après l’envoi, la chaîne du mot de passe est immédiatement traitée par clear-string
    • Des sources comme auth-source, KeePass ou pass peuvent être ajoutées à ghostel-password-prompt-functions
  • Si OSC 52 est activé explicitement, un programme distant peut définir l’anneau de suppression d’Emacs et le presse-papiers système, et le collage est transmis via bracketed paste
  • Les notifications OSC 9 et OSC 777 sont transmises à ghostel-notification-function
    • Le gestionnaire par défaut utilise alert s’il est installé, sinon il se rabat sur message dans la zone d’écho
  • La progression OSC 9;4 transmet les états remove, set, error, indeterminate, pause ainsi qu’une valeur de 0 à 100
    • Un indicateur textuel par défaut et un indicateur animé basé sur spinner.el sont fournis

Images inline Kitty

  • Le placement direct et le placement par placeholder Unicode U+10EEEE du protocole graphique Kitty sont pris en charge, ce qui permet de rendre les images de timg, kitty +kitten icat, yazi et autres
  • Les PNG sont traités par le décodeur stb intégré, et les données RGB, RGBA, Gray et GrayAlpha sont converties en PPM par le module natif, donc ImageMagick n’est pas nécessaire
  • Les requêtes de taille CSI 14, 16 et 18 t reçoivent une réponse, et le ratio de pixels physiques peut être défini avec ghostel-cell-pixel-scale
  • Le traitement des images comporte les limitations suivantes
    • Le canal alpha n’est pas composé mais supprimé, ce qui n’est pas adapté aux bords semi-transparents
    • Le recadrage partiel source-rect de Kitty n’est pas pris en charge et renvoie une erreur explicite
    • Plusieurs placements virtuels dans un même buffer partagent un seul rendu, et la transmission la plus récente est prioritaire
    • Par défaut, seul le base64 inline est autorisé ; les médias via fichier, fichier temporaire ou mémoire partagée doivent être activés explicitement pour des raisons de sécurité
    • La limite de stockage graphique par défaut est de 320 MiB par terminal

TRAMP et terminfo distant

  • Si default-directory est un chemin TRAMP, le shell est exécuté sur l’hôte POSIX correspondant, et les méthodes TRAMP de type SSH ainsi que les shells comme docker peuvent être définis via ghostel-tramp-shells
    • login-shell détecte le shell de connexion de l’utilisateur distant avec getent passwd
    • Le suivi de répertoire OSC 7 conserve la méthode, l’utilisateur et le préfixe multi-saut existants de TRAMP
    • Les cibles distantes Windows ne sont pas prises en charge dans ce chemin shell/tty POSIX
  • L’intégration shell distante n’est pas injectée par défaut, et deux méthodes sont proposées
    • Avec ghostel-tramp-shell-integration=t, un script temporaire est transféré puis nettoyé à la fermeture
    • Pour des hôtes permanents, les scripts de etc/shell/ et éventuellement terminfo peuvent être installés directement
  • Si xterm-ghostty terminfo n’est pas présent à distance, l’ouverture du terminal peut échouer ; ghostel-ssh-install-terminfo gère alors l’installation
    • L’exécution via TRAMP transfère terminfo dans un répertoire temporaire via la connexion existante, puis le supprime à la fermeture
    • Un ssh lancé depuis Ghostel en local normalise la cible avec ssh -G, consulte le cache, puis exécute si nécessaire tic -x - via une connexion supplémentaire unique
    • Le hash du terminfo local est inclus dans la clé de cache, ce qui l’invalide automatiquement lors des mises à jour de libghostty, mais les modifications séparées du terminfo à distance ne sont pas détectées
    • L’installation est ignorée pour ssh HOST cmd, les appels d’option sans hôte, ou si infocmp n’est pas disponible en local
  • Si vous ne souhaitez pas modifier l’hôte distant, vous pouvez désactiver l’installation automatique et installer terminfo manuellement ; en remplaçant ghostel-term par xterm-256color, cette configuration devient inutile, mais le chemin rapide de sortie synchronisée propre à Ghostty disparaît aussi

Fonctions d’extension Emacs

  • evil-ghostel synchronise les états insertion et normal d’Evil avec le curseur du terminal
    • Sont pris en charge : déplacement, insertion, suppression, modification, remplacement, bracketed paste, annulation readline et forme du curseur selon l’état
    • Cela n’affecte pas vim, less ou htop sur écran alternatif
  • ghostel-compile exécute les commandes sur un vrai PTY tout en fournissant des en-têtes, pieds de page, surlignage des erreurs et navigation next-error au format compilation-mode
    • Par défaut, il s’agit d’une navigation en lecture seule, mais un argument préfixe permet de transmettre une saisie interactive
    • Même pendant l’exécution, il est possible de basculer entre saisie interactive et navigation de compilation avec C-c C-j et C-c C-e ou C-c C-t
    • ghostel-compile-global-mode envoie vers Ghostel les appels à compile, recompile, project-compile et compilation-start
    • grep-mode conserve par défaut l’implémentation existante
  • ghostel-eshell-visual-command-mode exécute les commandes visuelles d’Eshell comme vim, htop ou less dans un buffer Ghostel dédié au lieu de term-mode
  • ghostel-comint-mode traite le flux de sortie comint avec libghostty-vt afin de fournir true color, plusieurs styles de soulignement, les liens OSC 8 et les mises à jour de répertoire OSC 7
    • Comme ce n’est pas un terminal complet, le positionnement du curseur, l’écran alternatif et le redessin plein écran sont ignorés, ce qui ne convient pas à htop ou less
  • ghostel-ime-mode efface puis transmet en UTF-8 au PTY le résultat des méthodes de saisie Elisp qui insèrent directement des caractères dans le buffer, comme pour le hangul
    • Pendant une composition Quail, le rendu est différé afin d’éviter que le buffer n’écrase la chaîne en cours de composition

Performances

  • Sur un Apple M4 Max avec Emacs 32.0.50, en envoyant 1 Mo via un vrai pipe de processus et en conservant environ 1 000 lignes de scrollback, on obtient les résultats suivants
    • ASCII standard : Ghostel 75MB/s, Ghostel avec détection de liens désactivée 76MB/s, vterm 18MB/s, eat 6.2MB/s, term intégré 7.2MB/s
    • Sortie riche en URL : Ghostel 36MB/s, Ghostel avec détection de liens désactivée 78MB/s, vterm 15MB/s, eat 4.5MB/s, term 5.9MB/s
  • La détection des URL et chemins de fichiers s’exécute dans un timer unifié hors du chemin de redessin, ce qui n’a presque aucun coût sur une sortie normale, mais réduit le débit d’environ moitié sur une sortie dense en liens
  • Pour une comparaison équitable, les chiffres ci-dessus utilisent le chemin de processus Emacs ; le PTY natif local par défaut est environ 2 fois plus rapide sur des dumps volumineux continus, car le thread de fond Zig lit la sortie
  • La médiane sur 5 exécutions d’un cat sur un fichier de 10 Mo est d’environ 110 ms pour Ghostel natif, environ 220 ms pour Ghostel via PTY Emacs, environ 550 ms pour vterm et environ 1,8 seconde pour eat
    • vterm et eat monopolisent de façon synchrone le thread principal d’Emacs pendant le transfert, tandis que le PTY natif de Ghostel analyse en arrière-plan, ce qui permet à l’UI de rester réactive
  • M-x ghostel-debug-typing-latency mesure le minimum, la médiane, le p99 et le maximum de la latence PTY, du rendu et de la latence totale, touche par touche

Différences avec vterm et eat

  • vterm utilise un module natif C basé sur libvterm, tandis que eat est écrit entièrement en Elisp, donc portable sans compilation, au prix d’un débit plus faible
  • Seul Ghostel prend en charge à la fois le clavier et les graphismes Kitty, cinq types de soulignement, OSC 8, OSC 4/10/11, les notifications OSC 9·777, ainsi que la progression OSC 9;4 et DEC 2026
    • eat prend en charge les images Sixel mais pas les images Kitty, et vterm ne prend en charge aucun des deux protocoles d’image
  • Ghostel et eat transmettent les événements de souris SGR aux TUI, tandis que vterm utilise les clics pour déplacer le point Emacs
  • Ghostel et eat proposent un mode line, contrairement à vterm
    • Ghostel fournit à la fois un mode copy où la sortie s’arrête et un mode Emacs où la sortie continue
    • vterm propose un mode copy figé, tandis que le mode Emacs en lecture seule d’eat continue à se mettre à jour
  • Ghostel injecte automatiquement l’intégration shell, alors que vterm et eat nécessitent de charger manuellement un script
  • Les invites de mot de passe sont détectées automatiquement par Ghostel ; eat ne fournit qu’une commande d’envoi manuel, et vterm n’intercepte pas l’entrée séparément

Architecture interne

  • Pour les buffers locaux, Zig ouvre par défaut le PTY, crée le processus fils, puis transmet la sortie à libghostty-vt depuis un thread de fond
    • Lorsqu’un callback OSC ou un redessin est nécessaire, un événement Lisp est envoyé au pipe Emacs et traité par ghostel--events-filter
    • Les sorties volumineuses ne transitent pas octet par octet par le filtre de processus Emacs
  • Les buffers TRAMP reçoivent la sortie via le processus Emacs et la transmettent de façon synchrone au même modèle de terminal, afin de conserver la création distante et les file handlers
  • Les frappes passent par l’encodeur libghostty avant d’être écrites immédiatement dans le PTY, et la sortie passe par l’analyseur VT puis l’étape d’invalidation ; en cas d’écho interactif, le rendu est immédiat, sinon Renderer.zig met à jour les lignes modifiées via le timer unifié
  • Le rendu du terminal modifie le buffer Emacs via remplacement de lignes, redessin complet, redimensionnement et reflow, ainsi que l’ajout et la suppression de scrollback ; le renderer est donc responsable de la préservation du point, de la marque et de la position de la fenêtre
    • Elisp décide des politiques et de l’intention utilisateur, par exemple faut-il revenir au viewport actif après une saisie, ou préserver l’état de navigation selon le mode
    • Il faut éviter de corriger les changements du renderer avec des heuristiques Elisp avant/après redraw, car cela rend difficile la distinction entre défilement utilisateur, correction de redisplay, redimensionnement et réécriture du contenu

Tests et licence

  • Les tests sont basés sur ERT ; les tests Elisp peuvent s’exécuter sans le module Zig, et les tests tagués native nécessitent le module compilé
    • Des cibles Makefile sont fournies pour les tests unitaires Zig, la suite complète, les tests de l’extension Evil et les benchmarks rapides
  • Les bugs, demandes de fonctionnalités et pull requests sont acceptés sur le dépôt GitHub ; pour les problèmes de rendu, il faut fournir une commande de reproduction, la séquence d’échappement, la version d’Emacs et les informations de plateforme
  • M-x ghostel-debug-info permet de collecter les événements de diagnostic
  • Ghostel est un logiciel libre distribué sous GNU GPL v3 ou ultérieure

À lire aussi

3 commentaires

 
lum7671 1 시간 전

On dirait que la saisie en coréen ne fonctionne pas.
Même avec Ctrl-\, il semble que la méthode de saisie bascule bien en coréen, mais en pratique seule la saisie en anglais fonctionne.
C’est un peu dommage.
 
GN⁺ 2 시간 전
Avis sur Lobste.rs
  • J’estime que Ghostel est la solution ultime pour l’émulation de terminal dans Emacs. Pour une simple fenêtre de terminal ponctuelle, j’utilise le vrai Ghostty, et pour le travail sur un projet, j’utilise Ghostel relié à ce projet via la commande ghostel-project
    S’il existe déjà une instance pour le projet, on bascule directement dessus, donc il est très rapide de passer d’un terminal à l’autre
  • Ça me donne envie de réessayer Doom Emacs pour voir à quel point l’intégration fonctionne bien. L’une des raisons pour lesquelles j’avais abandonné la dernière fois, c’était l’instabilité du terminal d’Emacs
    • Moi aussi, j’ai envie d’essayer. vterm a quelques limites, mais le fait de pouvoir utiliser les commandes de l’éditeur telles quelles même dans le terminal est vraiment appréciable
      Quand on parle d’émulation de terminal dans Emacs, on reçoit souvent comme réponse qu’il suffit d’utiliser dired au lieu de cd/mv/ls/cp/rm/mkdr/..., ou compile au lieu des commandes de build, alors pourquoi en avoir besoin. Mais même sans faire de tâches complexes, le terminal paraît plus familier et plus flexible
      S’il existe un guide expliquant comment réduire sa dépendance au terminal dans Doom Emacs, j’aimerais bien l’essayer. Voir des gens naviguer rapidement dans leurs projets avec des réglages avancés est toujours impressionnant
    • L’émulation de terminal dans Emacs est arrivée à un niveau presque parfaitement utilisable, mais certains outils de terminal d’anciennes générations se cassent encore dans des environnements comme vterm, et des problèmes de calcul de taille de ligne font que l’écran de jj se retrouve parfois complètement déréglé, ce qui est frustrant
      Au final, je garde quand même Ghostty ouvert à côté, mais j’espère qu’un jour tous les outils fonctionneront correctement dans Emacs
  • Il semble ne pas y avoir de fonctionnalité équivalente à eat-eshell, donc c’est difficile pour moi de le choisir. Une émulation de terminal plus rapide m’intéresse, mais j’utilise beaucoup eshell
    Avec eat-eshell, des programmes qui nécessitent une émulation de terminal comme les outils de build, le CLI de Podman ou les applications TUI fonctionnent directement dans un buffer eshell, donc pour les personnes qui utilisent souvent eshell, c’est une fonctionnalité qui change complètement la donne
    • On peut aussi le faire dans un terminal, donc je me demande à quoi sert spécifiquement eshell. Comme je n’utilise pas beaucoup eshell, j’ai souvent l’impression de passer à côté de son intérêt
 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • Je suis le mainteneur principal de Ghostel. Avec baokaola, nous comptions publier un Show HN la semaine prochaine, mais quelqu’un a soumis le lien avant nous
    Pour un aperçu rapide, le dépôt GitHub est plus pratique : https://github.com/dakra/ghostel
    Ghostel est un émulateur de terminal Emacs basé sur libghostty-vt, et une comparaison de fonctionnalités avec vterm et eat est disponible sur https://dakra.github.io/ghostel/#ghostel-vs-vterm. Il y a aussi un comparatif en images des performances et de la précision : https://gist.github.com/dakra/4a0b76ebcf5d52338e134864378465...
    Personnellement, il a remplacé non seulement vterm/eat, mais aussi des terminaux externes comme kitty et Ghostty. Le fait de pouvoir traiter le texte du terminal comme un buffer Emacs ordinaire ouvre énormément de possibilités d’extension absentes des autres terminaux. Même une tâche simple comme rechercher dans le scrollback, puis se déplacer et sélectionner un paragraphe à copier uniquement au clavier, est bien plus naturelle et rapide pour un utilisateur d’Emacs
    Si vous essayez Ghostel et gardez quand même un terminal externe, je serais curieux de savoir si c’est à cause de fonctionnalités manquantes ou parce que vous voulez exécuter certains processus hors d’Emacs. Nous sommes aussi très réactifs sur GitHub, donc n’hésitez pas à ouvrir une issue en cas de problème

    • Jusqu’ici, Ghostel fonctionne très bien. J’ai assigné f1 au basculement entre le mode semi-char et le mode copie, et avant d’exécuter une commande, je me demande : « est-ce grave si Emacs plante ou est forcé de quitter ? » Si oui, je la lance dans un terminal classique
    • Quand Magit et autres analysent de gros diff, tout Emacs peut se figer, donc au final je garde quand même un terminal séparé
    • Dans eshell, on peut manipuler le texte exactement comme dans n’importe quel autre buffer Emacs. Si on lie à une touche une fonction qui entoure un mot de guillemets, elle marche telle quelle aussi dans eshell, et on peut également utiliser evil-mode, xah-fly-keys et ispell, ce qui est un avantage décisif
      Ghostel n’est pas intégré au même niveau, et des extensions comme evil-ghostel-mode ont aussi leurs limites. Je me demande s’il est prévu d’améliorer cela, ou si c’est une contrainte structurelle à accepter, et une fonctionnalité équivalente à eat-eshell-mode serait excellente
    • J’aimerais bien un mode Quick-select basé sur des motifs comme dans WezTerm. Depuis que j’ai découvert cette fonctionnalité, je n’ai plus envie d’utiliser d’autres terminaux
    • Je l’utilise depuis un moment dans Doom Emacs et ça marche bien. Je me demande pourquoi des programmes qui font défiler l’écran, comme Lazygit ou Reasonix, échouent dans d’autres émulateurs mais fonctionnent dans Ghostel. J’aimerais savoir s’il y a un traitement particulier dans l’implémentation ou dans la bibliothèque

  • Le titre doit contenir Emacs. Un émulateur de terminal généraliste et un émulateur de terminal pour Emacs, ce n’est pas la même chose

    • Si on ne connaît pas le projet, il est plus utile de pointer vers https://github.com/dakra/ghostel que vers la documentation
    • .el est l’extension de fichier d’Emacs Lisp

  • Je suis passé récemment de vterm à Ghostel, et globalement c’est bien meilleur. C’est visiblement rapide, au point que même les applis TUI sophistiquées qui rafraîchissent tout le terminal à chaque frame tournent correctement, la gestion des entrées est plus stable et l’API ELisp est bonne
    En revanche, il m’est arrivé qu’il n’efface pas correctement le terminal, laissant des déchets au-dessus du prompt actuel, ou qu’il se fige complètement, m’obligeant à fermer le buffer et redémarrer. Pour un usage quotidien, c’est déjà largement utilisable et prometteur, mais pour devenir un produit mature, il faut encore corriger des bugs et peaufiner l’ensemble

    • Je suis co-mainteneur de Ghostel. Même si vous n’avez pas d’étapes de reproduction, si vous avez des informations exploitables, merci d’ouvrir une issue ou de nous les transmettre autrement
      Le problème des déchets en haut de l’écran peut correspondre à https://github.com/dakra/ghostel/issues/495, corrigé dans la dernière version, mais il peut aussi s’agir d’un autre bug. La partie difficile consiste à répliquer les données internes de libghostty-vt dans un buffer Emacs en ne remplaçant que les sections nécessaires. Il existe des tests basés sur les propriétés pour valider cela largement, mais certains problèmes passent parfois à travers
      Dans la release la plus récente, la gestion du cycle de vie a aussi été améliorée, ce qui a pu résoudre certains problèmes en même temps. Le projet est encore jeune, donc nous comptons le polir progressivement

  • J’aimerais voir de vrais exemples pratiques d’utilisation efficace des différents modes d’entrée. Le terminal veut toutes les frappes, tandis que l’éditeur veut aussi utiliser les touches pour ses propres commandes, donc un terminal intégré à l’éditeur a forcément besoin de modes qui basculent la propriété du clavier
    :term de Neovim n’a que deux modes, et si on ne comprend pas pourquoi Ghostel en a cinq, on peut facilement croire à une surconception. En réalité, cette complexité résout davantage de problèmes, et les modes supplémentaires sont des outils optionnels pour des tâches que nvim ne couvre pas. Mais la manière de tirer efficacement parti de cet avantage en pratique n’est pas encore suffisamment claire

  • J’avais du mal avec vterm, puis j’ai testé Ghostel et c’est excellent, au point qu’il pourrait devenir mon terminal principal

    • Je suis passé de vterm à eat puis à Ghostel, et jusqu’à présent Ghostel est le meilleur à mes yeux

  • Je l’utilise depuis plus d’un mois, et j’aime particulièrement la fonction qui permet de cliquer sur les références de code dans les résumés Codex pour les ouvrir directement dans un buffer Emacs

    • En plus de la souris, on peut se déplacer rapidement entre les hyperliens récemment affichés avec ghostel-previous-hyperlink ou ghostel-next-hyperlink
      Une map repeat-mode est aussi installée, donc s’il y a trois URL ou liens de fichiers dans la sortie, j’utilise souvent C-c C-p p p RET pour ouvrir le premier lien

  • Grâce à l’intégration entre Ghostel et Claude Code, j’utilise beaucoup plus Emacs, qui est désormais le hub central de mon travail

    • Ici, par intégration, tu veux dire que le modèle manipule directement Emacs via un serveur ?

  • Avec une dizaine de terminaux répartis dans quelques fenêtres, Ghostty plantait presque toutes les nuits. Du coup, je n’ai jamais pu vraiment l’utiliser, et je n’ai pas envie de l’intégrer à un outil dont je me sers tous les jours

    • J’utilise Ghostty 1.1.3 sur Gentoo Linux, et j’exécute actuellement plus de 100 instances de shell avec environ 20 onglets dans chacune d’une douzaine de fenêtres
      J’ai même lancé ls -lR dans autant de shells que possible sur un système de fichiers contenant plusieurs millions de fichiers, sans rencontrer de problème ni de plantage. Je l’utilise intensivement tous les jours depuis des mois et je n’ai jamais vu de crash ni de comportement suspect
      Cela ressemble davantage à un bug d’une version précise de Ghostty, ou à une interaction particulière avec un autre logiciel, comme le pilote GPU. Ici, j’utilise un GPU NVIDIA

  • Il est écrit que « les modules natifs sont des binaires précompilés téléchargés automatiquement lors de la première utilisation », mais je me demande pourquoi ils ne sont pas inclus dans le paquet distribué

    • MELPA et ELPA n’ont pas de moyen de joindre des fichiers spécifiques à chaque plateforme et distribuent tout via des checkouts Git. Pour les inclure dans la distribution, il faudrait mettre dans le dépôt les binaires des modules pour toutes les plateformes, ce qui représenterait plus de 10 Mo au total
      Jinx, un paquet populaire qui utilise aussi des modules natifs Emacs, propose comme vterm une compilation au premier usage. Donc, pour offrir une installation conviviale dans un paquet Emacs, il n’y a en pratique que deux possibilités : télécharger ou compiler au premier lancement