Ghostel.el – Emacs-Terminalemulator auf Basis von libghostty

 (dakra.github.io)
1 Punkte von GN⁺ 4 시간 전 | 3 Kommentare | Auf WhatsApp teilen
  • Ghostel ist ein Emacs-Terminalemulator, der dieselbe libghostty-vt-Engine wie Ghostty nutzt: Ein natives Zig-Modul übernimmt Terminalzustand, Rendering sowie lokale PTY-Ein-/Ausgabe, während Elisp Keymaps, Buffer, Befehle und Remote-Prozesse verwaltet
  • Unterstützt werden das Kitty-Tastatur- und Grafikprotokoll, OSC-8-Hyperlinks, OSC-4/10/11-Farbabfragen, synchronisierte Ausgabe nach DEC 2026 sowie fünf Eingabemodi; für lokale bash, zsh, fish und nushell wird die Shell-Integration automatisch angewendet
  • Unterstützt werden Emacs 28.1 oder neuer sowie macOS, Linux, FreeBSD und natives Windows; beim ersten Einsatz können plattformspezifische vorgebaute Module automatisch heruntergeladen werden, sodass für eine typische Installation keine Zig-Toolchain nötig ist
  • Ein Benchmark auf Apple M4 Max und Emacs 32.0.50, der 1 MB Ausgabe verarbeitete, ergab für normales ASCII 75 MB/s mit Ghostel, 18 MB/s mit vterm und 6,2 MB/s mit eat; das native PTY absorbiert eine 10-MB-cat-Operation in etwa 110 ms
  • Geboten werden außerdem TRAMP-Remote-Terminals, Schutz bei Passworteingaben, Kitty-Inline-Bilder sowie Integration mit Compilation, Eshell, Comint, Evil und Eingabemethoden; bei Remote-Zielen und Bildverarbeitung gibt es jedoch plattform- und protokollbedingte Einschränkungen

Aufbau und Installation

  • Ghostel ist vom zweischichtigen Design von emacs-libvterm inspiriert, nutzt statt libvterm jedoch Ghosttys moderne VT-Engine
    • Das Zig-Modul verarbeitet Terminalzustand, Rendering, Tastencodierung, lokale PTYs und Hintergrund-Lesevorgänge
    • Elisp ist für Keymaps, Buffer, Befehle, Projektintegration und TRAMP-Remote-Prozesse zuständig
  • Voraussetzung sind Emacs 28.1 oder neuer mit Unterstützung für dynamische Module sowie macOS, Linux, FreeBSD oder natives Windows
    • Vorgebaute Binärdateien werden für aarch64-macos, x86_64-macos, x86_64-linux, aarch64-linux, x86_64-freebsd, x86_64-windows und aarch64-windows bereitgestellt
    • Für andere Plattformen oder Builds aus dem Quellcode ist Zig 0.15.2 erforderlich
  • Die Installation ist über MELPA, use-package :vc ab Emacs 30, :load-path oder ein manuelles require möglich; das Terminal wird mit M-x ghostel geöffnet
  • Wenn kein natives Modul vorhanden ist, wird je nach Einstellung von ghostel-module-auto-install ein Download oder eine Kompilierung aus dem Quellcode vorgeschlagen
    • M-x ghostel-download-module lädt die minimal unterstützte Binärdatei herunter; mit Präfixargument kann ein Release-Tag ausgewählt werden
    • M-x ghostel-module-compile baut das Modul mit zig build
    • Falls das Paketverzeichnis neu installiert werden kann, lässt sich mit ghostel-module-directory ein separater Speicherort festlegen
  • Der Quell-Build enthält die generierte Datei vendor/emacs-module.h, sodass in der Regel keine lokalen Emacs-Header nötig sind; der Header-Pfad kann über EMACS_INCLUDE_DIR oder EMACS_BIN_DIR geändert werden
    • Die kompilierte xterm-ghostty-terminfo ist unter etc/terminfo/ enthalten und liegt in einem zwischen BSD und ncurses portablen Format vor

Windows-Unterstützung

  • Unter nativem Windows-Emacs werden lokale Terminals über ConPTY ausgeführt; die Architektur der Modul-DLL muss nicht zu Windows, sondern zur Emacs-Architektur passen
  • Zusammen mit dem vorgebauten Modul werden die Hilfsdateien conpty.dll und OpenConsole.exe heruntergeladen; fehlen diese Dateien, wird auf die in Windows integrierte ConPTY-API zurückgegriffen
  • Spezielle benutzerdefinierte Emacs-Builds, etwa mit statischer CRT, werden nur nach Best-Effort-Prinzip unterstützt
  • TRAMP-Terminals unter Windows unterstützen nur POSIX-Remote-Ziele, das PTY befindet sich auf dem Remote-Host; dynamische Änderungen der Fenstergröße werden derzeit nicht unterstützt

Fünf Eingabemodi

  • Der standardmäßige semi-char-Modus sendet die meisten Tasten ans Terminal, belässt aber Ausnahmen wie C-c, C-x, C-u, C-h, M-x, M-:, C-\ bei Emacs
    • Er stellt Tasten für Interrupt, Suspend, EOF-Übertragung, bracketed paste, das Löschen des Scrollbacks sowie die Navigation zu Prompts und Hyperlinks bereit
  • Der char-Modus sendet alle Tasten ans Terminal und eignet sich damit für TUIs, die selbst C-x, M-x oder C-h verwenden; nur M-RET bleibt als Escape-Taste erhalten
  • Der Emacs-Modus empfängt weiterhin Terminalausgabe, setzt den Buffer aber auf schreibgeschützt und erlaubt Standard-Emacs-Navigation wie isearch, occur, Markieren und Kopieren
    • Normale Eingaben werden nicht an die Shell weitergegeben; nur absichtliches Einfügen mit C-y wird per bracketed paste gesendet
  • Der copy-Modus hält Terminalaktualisierungen an, damit stabil ausgewählt, navigiert und kopiert werden kann
    • In kopiertem Text werden Zeilenumbrüche entfernt, die durch Soft Wrapping entstanden sind
    • Beim Standardwert ghostel-readonly-fast-exit=t kehrt Ghostel nach Zeicheneingabe oder Kopieren automatisch zur normalen Terminalsession zurück
  • Der line-Modus sendet Tasten nicht sofort an die Shell, sondern lässt eine Zeile im Emacs-Buffer bearbeiten und überträgt sie erst bei RET gesammelt
    • Auch wenn asynchrone Ausgabe oder ein neuer Prompt eintrifft, wird die gerade verfasste Eingabe als Snapshot bewahrt und anschließend wieder eingefügt
    • Ist OSC 133 vorhanden, werden Prompt-Grenzen verwendet; andernfalls werden sie mit ghostel-prompt-regexp gesucht
    • Beim Start einer Vollbild-TUI wird in den semi-char-Modus gewechselt und nach Beenden der TUI in den line-Modus zurückgekehrt
    • TAB nutzt comint-Completion und optional bash programmable completion
  • Beim Verlassen der Live-Eingabeposition durch Mausziehen, Mehrfachklicks, Aktivierung der Markierung, isearch oder consult-line wird standardmäßig in den copy-Modus gewechselt, um Auswahl und Position zu schützen
    • Hat eine TUI DEC-Maus-Tracking aktiviert, werden Mausevents im Eingabemodus an dieses Programm weitergereicht
    • Mit ghostel-mouse-drag-input-mode, ghostel-mark-activation-input-mode und ghostel-point-leave-input-mode lässt sich das Umschaltverhalten ändern

Terminalfunktionen und Rendering

  • Über libghostty-vt werden vollständige VT-Emulation, 256 Farben und 24-Bit-Farbe, Alternate Screen, mehrere Unterstreichungsstile und -farben, fett, kursiv, gedimmt, durchgestrichen, invertiert sowie vier Cursorformen und Blinken unterstützt
  • Das standardmäßige TERM=xterm-ghostty und die gebündelte terminfo melden Anwendungen Funktionen wie synchronisierte Ausgabe nach DEC 2026, Kitty-Tastatur, True Color, farbige Unterstreichungen und Fokusberichte
    • Über OSC-4/10/11-Abfragen können TUIs aus Emacs-Face-Farben Palette sowie Vorder- und Hintergrundfarbe beziehen
    • Die OSC-52-Zwischenablage wird unterstützt, ist standardmäßig aber deaktiviert, daher bewirbt die gebündelte terminfo die Ms-Funktion nicht
  • Der Standard-Scrollback beträgt 5 MB, etwa 5.000 Zeilen, und wird als Emacs-Buffer materialisiert, sodass er mit isearch und consult-line durchsucht werden kann
  • Zusätzlich zu OSC-8-Hyperlinks werden normale HTTP-/HTTPS-URLs und Dateipfade der Form /path/file.el:42 erkannt und als klickbare Links bereitgestellt
  • Unterstützt werden Ghosttys Tastencodierer und das Kitty-Tastaturprotokoll, SGR-Mausevents, DEC-1004-Fokusereignisse sowie Drag-and-drop von Dateipfaden und Text
  • Der Renderer überspringt unveränderte Zeilen, bündelt Updates per Timer und passt die Framerate adaptiv an
    • PTY-Echos, die direkt nach einer Tasteneingabe eintreffen, umgehen den standardmäßigen 33-ms-Timer und werden sofort gerendert
    • ghostel-sync-theme synchronisiert die Palette erneut passend zum Emacs-Theme
  • Die 16 ANSI-Farben sind Emacs-Faces, die term-color-* erben; mit ghostel-default lassen sich terminalspezifische Schriftart, Schriftgröße, Vorder- und Hintergrundfarbe einstellen

Shell-Integration und Emacs-Aufruf

  • Für bash, zsh, fish und nushell werden OSC-7-Verzeichnis-Tracking, OSC-133-Prompt-Navigation, OSC-2-Titel-Tracking und ghostel_cmd automatisch konfiguriert
    • Die Shell-Integration von nushell selbst stellt OSC 7, 133 und 2 bereit; ghostel.nu ergänzt ghostel_cmd und einen outbound-SSH-terminfo-Wrapper
    • Das in macOS enthaltene bash 3.2 ignoriert das für die automatische Injektion verwendete ENV; daher muss man ein aktuelles bash verwenden oder ghostel.bash manuell laden
  • ghostel_cmd zum Aufrufen von Elisp aus der Shell verwendet eine dedizierte OSC-52;e-Erweiterung und führt nur Funktionen aus, die in der Allowlist ghostel-eval-cmds stehen
    • Standardmäßig erlaubt sind find-file, find-file-other-window, dired, dired-other-window und message
  • Emacs-Lesezeichen speichern das Arbeitsverzeichnis des Terminals und den Buffernamen
    • Ist ein bestehender Buffer vorhanden, wird er wiederverwendet; andernfalls wird im gespeicherten Verzeichnis eine neue Shell gestartet
    • Scrollback und Sitzungsinhalte werden nicht gespeichert

Passwörter, Zwischenablage und Benachrichtigungen

  • Wenn Passwort-Prompts etwa von sudo, ssh, gpg oder passwd erkannt werden, wird read-passwd geöffnet und die Antwort direkt an das PTY gesendet, sodass die Eingabe nicht in view-lossage, dem Recent-Keys-Ring oder Tastaturmakros verbleibt
    • Lokal wird mit tcgetattr geprüft, ob der kanonische Modus und Echo deaktiviert sind
    • Nur bei Remote-Shells wird eine Regex-basierte Ersatzerkennung verwendet, um False Positives bei lokalen Raw-Mode-TUIs zu reduzieren
    • Nach dem Senden wird der Passwort-String sofort mit clear-string bereinigt
    • Über ghostel-password-prompt-functions lassen sich Quellen wie auth-source, KeePass oder pass hinzufügen
  • Wenn OSC 52 explizit aktiviert ist, können Remote-Programme den Emacs kill ring und die Systemzwischenablage setzen; Einfügen wird als bracketed paste übertragen
  • OSC-9- und OSC-777-Benachrichtigungen werden an ghostel-notification-function weitergeleitet
    • Der Standard-Handler verwendet alert, falls installiert, und fällt andernfalls auf message im Echo-Bereich zurück
  • OSC-9;4-Fortschritt übermittelt die Zustände remove, set, error, indeterminate und pause sowie Werte von 0 bis 100
    • Es werden ein einfacher Textindikator und ein animierter Indikator auf Basis von spinner.el bereitgestellt

Kitty-Inline-Bilder

  • Unterstützt werden direkte Platzierung und Platzierung über U+10EEEE-Unicode-Platzhalter im Kitty graphics protocol, sodass Bilder aus timg, kitty +kitten icat, yazi und anderen Tools gerendert werden
  • PNGs werden mit dem eingebetteten stb-Decoder verarbeitet, und RGB-, RGBA-, Gray- sowie GrayAlpha-Daten werden im nativen Modul nach PPM konvertiert, sodass ImageMagick nicht erforderlich ist
  • CSI-14-, -16- und -18-t-Größenabfragen werden beantwortet; mit ghostel-cell-pixel-scale lässt sich das Verhältnis physischer Pixel festlegen
  • Für die Bildverarbeitung gelten folgende Einschränkungen
    • Alphakanäle werden nicht zusammengesetzt, sondern entfernt; daher ist dies für halbtransparente Kanten ungeeignet
    • Kitty-source-rect-Zuschnitt wird nicht unterstützt und gibt einen expliziten Fehler zurück
    • Mehrere virtuelle Platzierungen im selben Buffer teilen sich ein Rendering; die zuletzt übertragene hat Vorrang
    • Standardmäßig ist nur inline base64 erlaubt; Datei-, temporäre Datei- und Shared-Memory-Medien müssen aus Sicherheitsgründen explizit aktiviert werden
    • Das standardmäßige Grafik-Speicherlimit pro Terminal beträgt 320 MiB

TRAMP und Remote-terminfo

  • Wenn default-directory ein TRAMP-Pfad ist, wird die Shell auf dem entsprechenden POSIX-Host ausgeführt; SSH-artige TRAMP-Methoden und Shells wie docker können über ghostel-tramp-shells festgelegt werden
    • login-shell erkennt die Login-Shell des Remote-Benutzers über getent passwd
    • Das OSC-7-Verzeichnis-Tracking bewahrt Methode, Benutzer und Multi-Hop-Präfixe des bestehenden TRAMP-Pfads
    • Windows-Remote-Ziele werden auf diesem POSIX-Shell-/tty-Pfad nicht unterstützt
  • Die Remote-Shell-Integration wird standardmäßig nicht injiziert; es gibt zwei Varianten
    • Mit ghostel-tramp-shell-integration=t wird ein temporäres Skript übertragen und beim Beenden bereinigt
    • Auf persistenten Hosts können die Skripte aus etc/shell/ und optional terminfo direkt installiert werden
  • Fehlt auf dem Remote-System die terminfo xterm-ghostty, kann das Öffnen des Terminals fehlschlagen; ghostel-ssh-install-terminfo übernimmt die Installation
    • Bei TRAMP-Ausführung wird terminfo über die bestehende Verbindung in ein temporäres Verzeichnis übertragen und beim Beenden gelöscht
    • Ein aus dem lokalen Ghostel gestartetes ssh normalisiert das Ziel mit ssh -G, prüft den Cache und führt bei Bedarf über eine einzelne zusätzliche Verbindung tic -x - aus
    • Der lokale terminfo-Hash ist im Cache-Key enthalten, sodass er bei Updates von libghostty automatisch ungültig wird; separat auf dem Remote-System geänderte terminfo wird jedoch nicht erkannt
    • Bei ssh HOST cmd, Optionsaufrufen ohne Host oder wenn lokal kein infocmp vorhanden ist, wird die Installation übersprungen
  • Wer den Remote-Host nicht verändern möchte, kann die automatische Installation deaktivieren und terminfo manuell installieren; wenn ghostel-term auf xterm-256color geändert wird, sind die zugehörigen Einstellungen nicht nötig, allerdings entfällt dann auch der Ghostty-spezifische High-Speed-Pfad für synchronisierte Ausgabe

Emacs-Erweiterungen

  • evil-ghostel synchronisiert Evils Insert- und Normal-State mit dem Terminal-Cursor
    • Unterstützt werden Bewegungen, Einfügen, Löschen, Ändern, Ersetzen, bracketed paste, readline undo und zustandsabhängige Cursorformen
    • Auf vim, less und htop im alternate screen wirkt es sich nicht aus
  • ghostel-compile führt Befehle in einem echten PTY aus und bietet zugleich Header, Footer, Fehlerhervorhebung und next-error-Navigation im Stil von compilation-mode
    • Standardmäßig ist dies eine schreibgeschützte Navigation; mit Präfixargument werden interaktive Eingaben weitergeleitet
    • Auch während der Ausführung kann mit C-c C-j und C-c C-e oder C-c C-t zwischen interaktiver Eingabe und Compile-Navigation umgeschaltet werden
    • ghostel-compile-global-mode leitet Aufrufe von compile, recompile, project-compile und compilation-start an Ghostel weiter
    • grep-mode behält standardmäßig die bestehende Implementierung bei
  • ghostel-eshell-visual-command-mode führt Visual Commands von Eshell wie vim, htop oder less statt in term-mode in einem dedizierten Ghostel-Buffer aus
  • ghostel-comint-mode verarbeitet comint-Ausgabeströme mit libghostty-vt und bietet true color, verschiedene Unterstreichungen, OSC-8-Links und OSC-7-Verzeichnisaktualisierungen
    • Da es kein vollständiges Terminal ist, entfallen Cursorpositionierung, alternate screen und vollständiges Neuzeichnen des Bildschirms; für htop oder less ist es nicht geeignet
  • ghostel-ime-mode löscht die Ergebnisse von Elisp-Eingabemethoden, die Zeichen wie Hangul direkt in den Buffer einfügen, und leitet sie anschließend als UTF-8 an das PTY weiter
    • Während einer Quail-Komposition wird das Rendering verzögert, damit der Buffer den Kompositionsstring nicht überschreibt

Performance

  • Gemessen auf einem Apple M4 Max mit Emacs 32.0.50, indem 1 MB über eine echte Prozess-Pipe gesendet und etwa 1.000 Zeilen Scrollback beibehalten wurden; die Ergebnisse waren wie folgt:
    • Einfaches ASCII: Ghostel 75 MB/s, Ghostel mit deaktivierter Link-Erkennung 76 MB/s, vterm 18 MB/s, eat 6,2 MB/s, eingebautes term 7,2 MB/s
    • Ausgabe mit vielen URLs: Ghostel 36 MB/s, Ghostel mit deaktivierter Link-Erkennung 78 MB/s, vterm 15 MB/s, eat 4,5 MB/s, term 5,9 MB/s
  • Die Erkennung von URLs und Dateipfaden läuft in einem zusammengefassten Timer außerhalb des Redraw-Pfads und verursacht bei normaler Ausgabe kaum Kosten; bei linklastiger Ausgabe sinkt der Durchsatz jedoch auf etwa die Hälfte
  • Für einen fairen Vergleich nutzen die obigen Werte den Emacs-Prozesspfad; die standardmäßige lokale native PTY ist bei kontinuierlichen großen Dumps etwa doppelt so schnell, da ein Zig-Background-Thread die Ausgabe liest
  • Der Median aus fünf Durchläufen mit cat auf einer 10-MB-Datei beträgt etwa 110 ms für natives Ghostel, etwa 220 ms für Emacs-PTY-Ghostel, etwa 550 ms für vterm und etwa 1,8 Sekunden für eat
    • vterm und eat belegen während der Übertragung synchron den Emacs-Main-Thread, während Ghostels native PTY im Hintergrund parst, sodass die UI weiter reagiert
  • M-x ghostel-debug-typing-latency misst Minimum, Median, p99 und Maximum der PTY-, Rendering- und Gesamtlatenz pro Taste

Unterschiede zu vterm und eat

  • vterm nutzt ein C-basiertes natives libvterm-Modul, während eat in reinem Elisp geschrieben ist und daher ohne Build portabel ist, dafür aber einen geringeren Durchsatz hat
  • Nur Ghostel unterstützt Kitty-Keyboard und -Grafik, fünf Arten von Unterstreichungen, OSC 8, OSC 4/10/11, OSC-9- und OSC-777-Benachrichtigungen, OSC-9;4-Fortschritt sowie DEC 2026 vollständig
    • eat unterstützt Sixel-Bilder, aber keine Kitty-Bilder; vterm unterstützt keines der beiden Bildprotokolle
  • Ghostel und eat leiten SGR-Mausereignisse an TUIs weiter, während vterm Klicks zur Bewegung des Emacs-Punkts verwendet
  • Ghostel und eat bieten einen Line-Modus, vterm dagegen nicht
    • Ghostel bietet sowohl einen Copy-Modus, in dem die Ausgabe anhält, als auch einen Emacs-Modus, in dem die Ausgabe weiterläuft
    • vterm bietet einen statischen Copy-Modus, und der read-only Emacs-Modus von eat wird weiter aktualisiert
  • Ghostel injiziert Shell-Integration automatisch, während vterm und eat Skripte manuell laden müssen
  • Passwort-Prompts erkennt Ghostel automatisch; eat bietet nur einen manuellen Sendebefehl, und vterm fängt Eingaben nicht separat ab

Interne Architektur

  • Bei lokalen Buffern öffnet standardmäßig Zig die PTY, erzeugt den Kindprozess und leitet die Ausgabe in einem Background-Thread an libghostty-vt weiter
    • Wenn OSC-Callbacks oder Redraws nötig sind, werden Lisp-Events über eine Emacs-Pipe gesendet und von ghostel--events-filter verarbeitet
    • Große Ausgaben durchlaufen den Emacs-Prozessfilter nicht byteweise
  • TRAMP-Buffer empfangen die Ausgabe über einen Emacs-Prozess und leiten sie synchron an dasselbe Terminalmodell weiter, um Remote-Erzeugung und File-Handler beizubehalten
  • Tastatureingaben werden über den libghostty-Encoder sofort in die PTY geschrieben; Ausgaben durchlaufen den VT-Parser und die Invalidierungsphase und werden bei interaktivem Echo sofort aktualisiert, andernfalls aktualisiert Renderer.zig die geänderten Zeilen in einem zusammengefassten Timer
  • Da das Terminal-Rendering den Emacs-Buffer durch Zeilenersetzung, vollständiges Neuzeichnen, Größenänderung mit Reflow sowie Hinzufügen und Löschen von Scrollback verändert, ist der Renderer dafür verantwortlich, Punkt, Marke und Fensterposition zu erhalten
    • Elisp entscheidet über Richtlinien und Nutzerabsicht, etwa ob nach einer Eingabe zum Live-Viewport gewechselt wird oder ob der Navigationszustand in den jeweiligen Modi erhalten bleibt
    • Es sollte vermieden werden, Renderer-Änderungen mit Elisp-Heuristiken vor und nach dem Redraw zu korrigieren, da es schwer ist, zwischen User-Scrolling, Redisplay-Korrektur, Größenänderung und Content-Rewrite als Ursache zu unterscheiden

Tests und Lizenz

  • Die Tests basieren auf ERT; Elisp-Tests können ohne Zig-Modul ausgeführt werden, während Tests mit dem Tag native ein gebautes Modul benötigen
    • Es gibt Makefile-Targets für Zig-Unit-Tests, vollständige Tests, Evil-Erweiterungstests und schnelle Benchmarks
  • Bugs, Feature-Requests und Pull Requests werden im GitHub-Repository entgegengenommen; bei Rendering-Problemen werden Reproduktionsbefehl, Escape Sequence, Emacs-Version und Plattforminformationen benötigt
  • Mit M-x ghostel-debug-info können Diagnose-Events gesammelt werden
  • Ghostel ist freie Software und wird unter der GNU GPL v3 oder neuer veröffentlicht

Verwandte Beiträge

3 Kommentare

 
lum7671 1 시간 전

Die koreanische Eingabe scheint nicht zu funktionieren.
Auch mit Ctrl-\ scheint der Eingabemodus zwar auf Koreanisch umzuschalten, aber tatsächlich scheint nur englische Eingabe möglich zu sein.
Das ist etwas schade.
 
GN⁺ 2 시간 전
Kommentare auf Lobste.rs
  • Ich sehe Ghostel als die endgültige Antwort auf Terminal-Emulation in Emacs. Für einfache, einmalige Terminalfenster nutze ich das echte Ghostty, und für Projektarbeit verwende ich mit dem Befehl ghostel-project ein Ghostel, das mit dem jeweiligen Projekt verbunden ist.
    Wenn es bereits eine Instanz für das Projekt gibt, wird direkt zu dieser gewechselt, sodass der Wechsel zwischen Terminals sehr schnell ist.
  • Ich bekomme Lust, Doom Emacs noch einmal auszuprobieren und zu sehen, wie gut die Integration funktioniert. Einer der Gründe, warum ich beim letzten Mal aufgegeben hatte, war die Instabilität des Emacs-Terminals.
    • Ich möchte es auch testen. Bei vterm gibt es Dinge, die mich stören, aber dass man auch im Terminal die Editor-Befehle unverändert verwenden kann, ist wirklich großartig.
      Wenn es in Emacs um Terminal-Emulatoren geht, kommt oft die Antwort, man könne doch statt cd/mv/ls/cp/rm/mkdr/... dired verwenden und statt Build-Befehlen compile – wozu brauche man das also? Aber selbst wenn man keine komplexen Aufgaben erledigt, fühlt sich ein Terminal vertrauter und flexibler an.
      Besonders wenn es eine Anleitung gäbe, wie man gerade in Doom Emacs die Abhängigkeit vom Terminal reduziert, würde ich sie gern ausprobieren. Zu sehen, wie man sich mit fortgeschrittener Konfiguration schnell durch Projekte bewegt, ist immer beeindruckend.
    • Die Terminal-Emulation in Emacs ist inzwischen fast perfekt brauchbar, und trotzdem gehen einige Generationen von Terminal-Tools in Umgebungen wie vterm kaputt; wegen Problemen bei der Berechnung der Zeilengröße gerät die Anzeige von jj gelegentlich völlig durcheinander, was frustrierend ist.
      Am Ende habe ich daneben Ghostty geöffnet, hoffe aber, dass eines Tages alle Tools innerhalb von Emacs korrekt funktionieren.
  • Da es offenbar keine Entsprechung zu eat-eshell gibt, ist die Wahl für mich schwierig. Ich habe zwar Interesse an schnellerer Terminal-Emulation, nutze aber eshell sehr viel.
    Mit eat-eshell funktionieren Programme, die Terminal-Emulation brauchen, wie Build-Tools und die Podman-CLI, sowie TUI-Anwendungen direkt im eshell-Buffer; für Leute, die eshell häufig nutzen, ist das ein echter Game Changer.
    • Mich würde interessieren, wofür man eshell separat verwendet, wenn man das doch auch im Terminal machen kann. Da ich eshell nicht viel nutze, habe ich oft das Gefühl, den Zweck davon zu übersehen.
 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Ich bin der Maintainer von Ghostel. baokaola und ich wollten nächste Woche einen Show HN posten, aber jemand hat den Link vorher eingereicht.
    Für einen schnellen Überblick ist das GitHub-Repository praktischer: https://github.com/dakra/ghostel
    Ghostel ist ein Emacs-Terminalemulator auf Basis von libghostty-vt; einen Funktionsvergleich mit vterm und eat gibt es unter https://dakra.github.io/ghostel/#ghostel-vs-vterm. Es gibt auch Material, das Performance und Genauigkeit anhand von Bildern vergleicht: https://gist.github.com/dakra/4a0b76ebcf5d52338e134864378465...
    Persönlich habe ich damit nicht nur vterm/eat ersetzt, sondern auch externe Terminals wie kitty und Ghostty. Wenn man Terminaltext wie einen normalen Emacs-Buffer behandelt, eröffnet das viele Erweiterungsmöglichkeiten, die es in anderen Terminals nicht gibt. Selbst einfache Dinge wie den Scrollback durchsuchen, dann nur mit der Tastatur navigieren, einen Absatz auswählen und kopieren, sind für Emacs-Nutzer viel natürlicher und schneller.
    Falls ihr Ghostel ausprobiert und trotzdem ein externes Terminal beibehaltet, würde mich interessieren, ob es an fehlenden Funktionen liegt oder daran, dass ihr manche Prozesse außerhalb von Emacs ausführen wollt. Wir reagieren auch auf GitHub aktiv; wenn es Probleme gibt, öffnet bitte ein Issue.

    • Bisher funktioniert Ghostel bei mir sehr gut. Ich habe f1 dem Umschalten zwischen Semi-Char-Mode und Copy-Mode zugewiesen und überlege vor dem Ausführen eines Befehls: „Ist es okay, wenn Emacs abstürzt oder hart beendet wird?“ Wenn nicht, führe ich ihn in einem normalen Terminal aus.
    • Weil Magit und Ähnliches beim Parsen großer Diffs ganz Emacs zum Einfrieren bringen können, behalte ich am Ende doch ein separates Terminal.
    • In eshell kann man Text genauso manipulieren wie in anderen Emacs-Buffern. Wenn man eine Funktion, die Wörter in Anführungszeichen setzt, an eine Taste bindet, funktioniert sie in eshell unverändert; auch evil-mode, xah-fly-keys und ispell lassen sich alle nutzen. Das ist der entscheidende Vorteil.
      Ghostel ist nicht auf demselben Niveau integriert, und Erweiterungen wie evil-ghostel-mode haben ebenfalls Grenzen. Mich würde interessieren, ob es Pläne gibt, das zu verbessern, oder ob das strukturelle Einschränkungen sind, die man hinnehmen muss. Eine Entsprechung zu eat-eshell-mode wäre großartig.
    • Ein patternbasierter Quick-select-Modus wie in WezTerm wäre schön. Seit ich diese Funktion kenne, möchte ich eigentlich kein anderes Terminal mehr verwenden.
    • Ich nutze es seit einiger Zeit erfolgreich in Doom Emacs. Mich würde interessieren, warum Programme, die den Bildschirm scrollen, wie Lazygit oder Reasonix, in anderen Emulatoren scheitern, in Ghostel aber funktionieren. Ich wüsste gern, ob es in der Implementierung oder Bibliothek eine besondere Behandlung dafür gibt.

  • Im Titel sollte Emacs stehen. Ein allgemeiner Terminalemulator und ein Terminalemulator für Emacs sind nicht dasselbe.

    • Wenn man das Projekt noch nicht kennt, ist ein Link zu https://github.com/dakra/ghostel nützlicher als die Dokumentation.
    • .el ist die Dateiendung für Emacs-Lisp-Dateien.

  • Ich bin kürzlich von vterm zu Ghostel gewechselt, und insgesamt ist es deutlich besser. Es ist spürbar schneller, schnell genug, dass auch aufwendige TUI-Apps, die in jedem Frame das ganze Terminal aktualisieren, sauber laufen; die Eingabeverarbeitung ist stabiler und die ELisp-API ist ebenfalls gut.
    Allerdings kam es vor, dass das Terminal nicht richtig gelöscht wurde und oberhalb des aktuellen Prompts Reste zurückblieben, oder dass es komplett hängen blieb und ich den Buffer schließen und neu starten musste. Für die tägliche Nutzung ist es ausreichend und die Aussichten sind gut, aber bis zu einem ausgereiften Produkt braucht es noch mehr Bugfixes und Feinschliff.

    • Ich bin Co-Maintainer von Ghostel. Auch wenn es keine Reproduktionsschritte gibt: Wenn ihr verwertbare Informationen habt, legt bitte ein Issue an oder gebt sie uns auf anderem Wege weiter.
      Das Phänomen mit Resten im oberen Bildschirmbereich könnte https://github.com/dakra/ghostel/issues/495 sein; das ist in der aktuellen Version behoben, es könnte aber auch ein anderer Bug sein. Der schwierige Teil besteht darin, die internen Daten von libghostty-vt in einen Emacs-Buffer zu spiegeln und dabei nur die nötigen Teile zu ersetzen. Dafür gibt es breit angelegte property-based Tests, aber gelegentlich rutscht dennoch etwas durch.
      In der aktuellen neuesten Version wurde das Lifecycle-Handling verbessert, wodurch einige Probleme mitbehoben worden sein könnten. Da das Projekt noch in einer frühen Phase ist, wollen wir es nach und nach verfeinern.

  • Es wäre gut, praktische Beispiele für den effizienten Einsatz der verschiedenen Eingabemodi zu haben. Ein Terminal will alle Tastatureingaben haben, während auch der Editor seine eigenen Befehle über Tasten auslösen möchte; ein im Editor eingebettetes Terminal braucht daher zwingend Modi, die den Besitz der Tastatur umschalten.
    Neovims :term hat nur zwei Modi; wenn man nicht versteht, warum Ghostel gleich fünf hat, hält man es leicht für überdesignt. Tatsächlich ist es komplexer, weil es mehr Probleme löst, und die zusätzlichen Modi sind optionale Werkzeuge für Aufgaben, die nvim nicht abdeckt. Allerdings ist noch nicht ausreichend klar, wie man diesen Vorteil in der Praxis effizient nutzt.

  • Nachdem ich mit vterm Schwierigkeiten hatte, habe ich Ghostel ausprobiert; es ist großartig und könnte mein Hauptterminal werden.

    • Ich bin von vterm über eat zu Ghostel gewechselt und finde, zumindest bisher, dass Ghostel am besten ist.

  • Ich nutze es seit über einem Monat, und besonders gut gefällt mir die in der Codex-Zusammenfassung erwähnte Funktion, Code-Referenzen anzuklicken und direkt in einem Emacs-Buffer zu öffnen.

    • Man kann nicht nur mit der Maus arbeiten, sondern mit ghostel-previous-hyperlink oder ghostel-next-hyperlink auch schnell zwischen kürzlich angezeigten Hyperlinks springen.
      Da auch eine repeat-mode-Map installiert wird, kann man, wenn in der Ausgabe drei URLs oder Dateilinks stehen, mit C-c C-p p p RET den ersten Link öffnen; das nutze ich häufig.

  • Durch die Integration von Ghostel und Claude Code nutze ich Emacs deutlich mehr; Emacs ist nun der zentrale Hub meiner Arbeit.

    • Mich würde interessieren, ob Integration hier bedeutet, dass das Modell über einen Server Emacs direkt steuert.

  • Wenn ich in ein paar Fenstern rund 10 Terminals offen hatte, stürzte Ghostty fast jede Nacht ab. Deshalb konnte ich Ghostty nicht wirklich nutzen und möchte es auch nicht in ein Tool einbetten, das ich täglich verwende.

    • Ich nutze Ghostty 1.1.3 unter Gentoo Linux und habe derzeit in etwa 12 Fenstern jeweils rund 20 Tabs offen, also über 100 Shell-Instanzen.
      Ich habe auf Dateisystemen mit Millionen Dateien in so vielen Shells wie möglich auch ls -lR ausgeführt, aber es gab keine Probleme oder Abstürze. Über Monate hinweg habe ich es täglich den ganzen Tag intensiv genutzt und weder Abstürze noch verdächtiges Verhalten gesehen.
      Es wirkt eher nach einem Bug in einer bestimmten Ghostty-Version oder nach einer ungewöhnlichen Wechselwirkung mit anderer Software, etwa dem GPU-Treiber. Hier verwende ich eine NVIDIA-GPU.

  • Es heißt: „Die nativen Module sind vorgefertigte Binärdateien und werden bei der ersten Verwendung automatisch heruntergeladen“; mich würde interessieren, warum man sie nicht ins Distributionspaket aufnimmt.

    • MELPA und ELPA haben keine Möglichkeit, plattformspezifische Dateien anzuhängen, und verteilen alles als Git-Checkout. Um sie in die Distribution aufzunehmen, müsste man die Modul-Binaries für alle Plattformen ins Repository legen; zusammen wären das über 10 MB.
      Das beliebte Emacs-Paket jinx, das ebenfalls native Emacs-Module nutzt, bietet wie vterm eine Variante, bei der beim ersten Einsatz kompiliert wird. Um in Emacs-Paketen eine nutzerfreundliche Installation zu unterstützen, bleibt daher realistisch nur, beim ersten Start herunterzuladen oder zu kompilieren.