Ich wollte nur, dass Emacs hübsch aussieht – 24-Bit-Farben im Terminal

 (chadaustin.me)
2 Punkte von GN⁺ 2024-01-31 | 1 Kommentare | Auf WhatsApp teilen
  • Damit Themes wie Solarized in Terminal-Emacs korrekt dargestellt werden, ist weniger die 24-Bit-Farbe selbst entscheidend als vielmehr, ob Terminal, terminfo, tmux und mosh dieselben Farbfähigkeiten durchgängig verstehen
  • RGB-Farben werden weit verbreitet in der Form ESC[38;2;<r>;<g>;<b>m verwendet, doch die standardnähere Doppelpunkt-Syntax und die in realen Implementierungen verbreitete Semikolon-Syntax existieren nebeneinander, was die Kompatibilität kompliziert macht
  • xterm-256color und xterm-direct werben jeweils mit einer 256-Farben-Palette bzw. 16.777.216 Farben, aber das palettenzentrierte Modell von terminfo kann direkte RGB-Farben nicht sauber ausdrücken
  • In realen Umgebungen können alternative TERM-Werte wie die -direct-Einträge aus ncurses-term, tmux-direct, die mosh-1.4-Reihe oder vscode-direct nötig sein; einige Schichten akzeptieren weiterhin nur die Semikolon-Variante
  • Um moderne Terminalfunktionen zuverlässig zu nutzen, reichen TERM und terminfo allein nicht aus; es braucht eine separate Darstellungsform, die Fähigkeiten schneller nach Terminalnamen und -version aktualisieren kann

Warum 24-Bit-Farben in Terminal-Emacs nötig sind

  • Emacs in einer grafischen Umgebung unterstützt 24-Bit-Farben automatisch und kann dadurch Themes wie Solarized und Schriftarten korrekt darstellen
  • Verwendet man dasselbe Theme im Terminal, ist die Farbdarstellung eingeschränkt, sodass der Bildschirm weniger ansprechend wirken kann
  • Beliebte Terminals unterstützen 24-Bit-Farben schon seit Langem, aber damit Programme sie nutzen können, müssen Fähigkeitserkennung und Konfiguration beide stimmen
  • Das Ziel ist zweierlei
    • herauszufinden, wie sich Truecolor in der aktuellen Terminalumgebung aktivieren lässt
    • nachzuvollziehen, wie Emacs-Farbprobleme mit Terminalstandards aus den 1970er bis 1990er Jahren zusammenhängen

ANSI-Escape-Codes und die Geschichte der Farberweiterungen

  • Frühe Hardware-Terminals nutzten unterschiedliche Systeme für Steuerzeichen, und für portable Software war eine ANSI-Standardisierung nötig
  • ANSI escape codes gehen auf die 1970er Jahre zurück; für Farben ist vor allem SGR (Select Graphics Rendition) zentral
    • Fett oder Helligkeit
    • Kursiv
    • Blinken
    • Vordergrund- und Hintergrundfarbe
    • weitere Darstellungsattribute für Zeichen
  • Anfangs waren Farben 3-Bit-Farben, entsprechend den 8 Ecken eines RGB-Würfels
    • einschließlich Schwarz, Weiß, additiver Primärfarben und subtraktiver Primärfarben
  • Später kamen helle Farben bzw. ein Fett-Bit hinzu, wodurch auf 16 Farben erweitert wurde
    • „bright black“ entspricht dabei einem dunklen Grau
  • 1999 ergänzte Todd Larason xterm per Patch um 256-Farben-Unterstützung
    • Sampling eines 6x6x6-RGB-Farbwürfels
    • 24-stufige Graustufenrampe
    • außerdem existiert eine seltene, aber weiterhin unterstützte 88-Farben-Variante

Wie die 24-Bit-Farbsyntax entstand

  • 8-Bit-Farben und 24-Bit-Farben werden in kompatiblen Terminals wie folgt gesetzt
    • ESC[38;5;<n>m: setzt die Palettenfarbe mit Nummer n als Vordergrundfarbe
    • ESC[38;2;<r>;<g>;<b>m: setzt die RGB-Werte r, g, b als Vordergrundfarbe
  • Die Zahlen 5 und 2 hängen mit dem erweiterten Farbmodus aus ISO 8613-6 bzw. ITU T.416 zusammen
    • 2: direkte Farbe im RGB-Raum
    • 5: Indexfarbe
  • Der Weg der Standardisierung verlief so
    • 1970er: ANSI standardisierte Terminal-Escape-Sequenzen, woraus ANSI X3.64 und ECMA-48 hervorgingen
    • 1979: Die 2. Ausgabe von ECMA-48 ordnete SGR 30–37 und 40–47 den 3-Bit-Vordergrund- und Hintergrundfarben zu
    • 1984: Die 3. Ausgabe von ECMA-48 führte das Konzept von Standard-Vordergrund und -Hintergrund ein und wies 39 und 49 zu
    • 1991: Die 5. Ausgabe von ECMA-48 ließ 38 und 48 „für zukünftige Standardisierung“ offen und verwies auf ISO 8613-6
    • 1993: ISO 8613-6 definierte 38 und 48 als erweiterten Vordergrund- bzw. Hintergrundfarbmodus
  • Für die Trennung von Unterparametern ist der Doppelpunkt standardnäher, in realen Implementierungen setzte sich jedoch das Semikolon breit durch
    • ESC[38;5;3m kann in Terminals, die SGR 38 nicht kennen, als getrennte Parameter 38, 5, 3 interpretiert werden
    • In den xterm-FAQ von Thomas Dickey wird erklärt, dass Kopien von ITU T.416 damals teuer waren und die Trennung von RGB-Werten per Semikolon wie bei anderen SGR-Parametern ein Fehler war
  • Die zugehörige Zeitleiste sieht so aus
    • 1999: Thomas Dickey übernahm Todd Larasons 256-Farben-Patch in xterm; dabei kam die mehrdeutige Semikolon-Syntax hinein
    • 2006: Konsole unterstützte 256 Farben und 24-Bit-Truecolor mit derselben Semikolon-Syntax wie xterm
    • 2012: xterm wurde so geändert, dass auch die standardnähere Doppelpunkt-Syntax akzeptiert wird
    • 2016: Die eingebaute Windows-10-Konsole unterstützte ANSI-Escape-Codes und 24-Bit-Farben, verwendete aber die Semikolon-Syntax
    • 2019: Windows Terminal unterstützt ebenfalls ANSI-Escape-Codes, verwendet aber die Semikolon-Syntax
    • 2022: Microsoft kündigte den Übergang des Ökosystems vom Legacy-Konsolensubsystem im VGA-Stil zur ANSI-Terminalemulation an
    • 2022: Konsole erhielt Unterstützung für die standardkonforme Doppelpunkt-Syntax

Wie terminfo Farbfähigkeiten beschreibt

  • terminfo stellt eine Datenbank für Terminalfähigkeiten sowie Funktionen zur Erzeugung passender Escape-Sequenzen bereit
  • Die Umgebungsvariable TERM zeigt auf den terminfo-Eintrag, den ein Programm verwenden soll, und wird auch bei ssh-Verbindungen automatisch weitergegeben
  • toe zeigt eine Liste installierter terminfo-Einträge, infocmp dient zur Prüfung der Fähigkeiten eines bestimmten Eintrags
  • Für Farben sind drei Fähigkeiten wichtig
    • colors: Anzahl der vom Terminal unterstützten Farben
    • setaf: Vordergrundfarbe setzen
    • setab: Hintergrundfarbe setzen
  • xterm-256color erzeugt bei setaf je nach Farbnummer unterschiedliche Sequenzen
    • 0–7: ANSI-SGR-Parameter 30–37
    • 8–15: nicht standardisierte helle Farben 90–97
    • darüber: 256-Farben-Palette in der Form 38;5;<n>
  • xterm-direct ist ein terminfo-Eintrag für 24-Bit-RGB und meldet colors als 16.777.216
    • ccc ist deaktiviert und signalisiert, dass Farbindexen keine neuen RGB-Werte zugewiesen werden können
    • Einträge für Laufzeit-Farbänderungen wie initc, oc und rs1 fehlen ebenfalls
    • setaf und setab verwenden die doppelpunktbasierte Form 38:2::...

Grenzen des Direct-Color-Modells in terminfo

  • Das Programmiermodell von terminfo und ncurses ist grundsätzlich auf Paletteneinträge ausgerichtet
    • es gibt N Paletteneinträge
    • jeder Eintrag hat einen Standard-RGB-Wert
    • angenommen wird ein Modell, in dem das Terminal diese Werte ändern kann
  • -direct-Terminals stellen 24-Bit-Farben dar, indem sie so tun, als gäbe es 16.777.216 Paletteneinträge
    • jeder Eintrag entspricht einem 8:8:8-RGB-Würfel
    • die Werte lassen sich nicht ändern
  • Zur Kompatibilität verwendet der xterm-direct-Ansatz die 7 dunkelsten Blautöne für die Kompatibilität mit den ANSI-Standard-8-Farben
    • Schwarz ist ausgenommen
    • damit soll vermieden werden, dass bestehende Programme, die von einer bestimmten Bedeutung von setaf ausgehen, fast unsichtbares dunkles Blau ausgeben
  • Dadurch sind -direct- und -256color-Ansätze nicht miteinander kompatibel
    • Programme müssen wissen, dass 256 Farben Indexfarben und 16.777.216 Farben direkte Farben sind
    • außerdem gibt es die Ausnahme, dass die 7 dunkelsten Blautöne vermieden werden sollten
  • In einem Problem rund um termwiz erwartete das Programm die xterm-256color-Palette, gab tatsächlich aber schwer lesbare dunkelblaue Töne aus
    • das betreffende Issue war zum Zeitpunkt des Schreibens noch offen, aber @quark-zju hatte einen Fix eingepflegt, sodass termwiz inzwischen sinnvoll funktioniert
  • Im Kern geht es eher um Beschränkungen von terminfo als um das Terminal selbst
    • Terminals mit 24-Bit-Farben scheinen auch die xterm-256color-Palette und dynamische Änderungen von RGB-Werten zu unterstützen
    • terminfo reicht nicht aus, um das moderne Ökosystem von Terminalemulatoren präzise und schnell abzubilden

TERM-Einstellung und Semikolon-Kompatibilität

  • Weil viele Programme terminfo nutzen, muss der TERM-Wert korrekt gesetzt sein
  • Selbst wenn man auf die doppelpunktbasierte SGR-Syntax vereinheitlichen möchte, unterstützen viele Umgebungen weiterhin nur die Semikolon-Syntax
    • die eingebaute Windows-Konsole Conhost
    • bestimmtes Verhalten in Mintty und Cygwin-Umgebungen
    • Mosh
    • PuTTY
    • die in Ubuntu 22.04 LTS enthaltene Konsole-Version
  • terminfo-Einträge bestehen aus Bausteinen
  • Beim Suchen nach xterm+indirect schien vscode-direct am besten zu passen
    • da es auf Microsoft-Terminals zielt, wurde es als ausreichend nah an Windows Terminal und Windows Console eingeschätzt
    • nicht alle Fähigkeiten wurden geprüft, aber es funktioniert
  • Auf vielen Servern sind -direct-terminfo-Einträge möglicherweise nicht installiert
    • auf den meisten Systemen liegt die Standard-terminfo-Datenbank im Paket ncurses-base
    • erweiterte Terminaleinträge erfordern das Paket ncurses-term
  • In ncurses wurde während des Schreibens ein winconsole-terminfo-Eintrag ergänzt, der aber keine 24-Bit-Farben unterstützt und noch in keiner ncurses-Version veröffentlicht war

Wie Emacs Truecolor erkennt

  • Emacs dokumentiert, wie die Erkennung von Truecolor-Unterstützung auf TTY erfolgt
  • Mit (display-color-cells) in M-x eval-expression lässt sich prüfen, ob Emacs 16.777.216 Farben erkennt
  • Die Emacs-Dokumentation behandelt auch die Grenzen von terminfo im -direct-Modus
    • Terminals mit der Fähigkeit RGB können #000001 bis #000007 als Indexfarben statt als direkte RGB-Werte behandeln
    • das dient der Abwärtskompatibilität mit Anwendungen, die Direct Color nicht kennen
    • falls das problematisch ist, kann man benutzerdefinierte Terminaldefinitionen mit setb24 und setf24 verwenden
  • Emacs sucht zuerst nach den Strings setf24 und setb24; falls sie fehlen, verwendet es RGB als Ersatzfähigkeit
  • In den geprüften terminfo-Einträgen war setf24 nicht enthalten

In verschachtelten Terminals müssen alle Schichten passen

  • Typische Arbeitsabläufe verschachteln mehrere Terminalschichten
    • lokalen grafischen Terminalemulator öffnen
    • per mosh auf einen entfernten Rechner oder eine VM verbinden
    • tmux starten
    • zusätzlich ein internes Emacs-Terminal, Asciinema, GNU Screen usw. verwenden
  • Jede Schicht implementiert ihren eigenen Zustandsautomaten für ANSI-Escape-Sequenzen
  • Damit 24-Bit-Farben funktionieren, müssen alle Schichten die Escape-Sequenzen verstehen, die vom terminfo-Eintrag des inneren TERM-Werts erzeugt werden, und sie korrekt an die äußere terminfo-Schicht weiterreichen
  • Entsprechend muss die betreffende Software ausreichend aktuell sein
    • das aktuelle Ubuntu LTS liefert mosh 1.3 aus, daher musste das mosh-dev-PPA aktiviert werden
  • Auch TERM innerhalb jeder Schicht muss stimmen
    • innerhalb von tmux wird tmux-direct verwendet
    • für mosh gibt es kein Standard-terminfo, daher muss ein ausreichend naher Wert gewählt werden

Konfiguration je nach Umgebung

  • Grafischer Terminalemulator

    • die meisten Terminals setzen einen passenden Standardwert für TERM oder erlauben dem Nutzer eine Überschreibung
    • in Konsole gibt es eine Option zur Auswahl des TERM-Werts

  • ssh

    • ssh übergibt den TERM-Wert an die neue Shell
    • wenn auf dem entfernten Host derselbe terminfo-Eintrag vorhanden ist, ist die Konfiguration vergleichsweise einfach

  • tmux

    • beim Start von tmux kann TERM auf screen gesetzt werden
    • das lässt sich durch Ändern des Standardterminals in ~/.tmux.conf beheben
    set -g default-terminal "tmux-direct"
    • man könnte tmux-direct auch nur dann bedingt setzen, wenn das äußere TERM 24-Bit-Farben unterstützt, und sonst screen oder tmux-256color beibehalten

  • mosh

    • aktuelles mosh unterstützt 24-Bit-Farben, meldet selbst aber nur 8 oder 256 Farben
    • daher muss der Nutzer TERM passend setzen
    • mosh zielt auf xterm-Kompatibilität, unterstützt bei SGR 38 und 48 aber nur die Semikolon-Syntax
    • TERM=xterm-direct funktioniert nicht
    • vscode-direct wurde als nächstliegende Alternative zu xterm-direct verwendet
    • da es keine bequeme Variable gibt, die anzeigt, ob mosh läuft, wurde das Skript detect-mosh.rs geschrieben und in .bashrc aufgerufen
    • dabei wird geprüft, ob der Shell-Prozess ein Kind von mosh-server ist
    • ob das Kompilieren von Rust im Login-Pfad für schwache Hosts geeignet ist, blieb offen

Endergebnis und verbleibende Probleme

  • Nach der Konfiguration wird das Theme auch in Emacs innerhalb von tmux und mosh mit 24-Bit-Farben dargestellt
  • Die verbleibenden Probleme lassen sich auf drei Punkte verdichten
    • Terminals sind sich bei Syntax und Fähigkeiten nicht vollständig einig
    • terminfo ist der standardmäßige Weg zur Abfrage von Fähigkeiten
    • terminfo ist begrenzt, manchmal ungenau, und neue Versionen erscheinen nicht besonders häufig

Die Richtung nach terminfo

  • Software, die moderne Terminalfunktionen umfassend nutzen will, muss sich von terminfo lösen
  • Mögliche Richtungen sind
    • die breit unterstützte Variable TERM weiterzuverwenden
    • Programme nicht nur auf veraltetes terminfo des Betriebssystems oder der Distribution zu stützen, sondern ihnen zu erlauben, Terminalfähigkeiten selbstständig zu kennen
    • Informationen über Terminalemulatoren der letzten etwa 10 Jahre nach Name und Version in häufig aktualisierten Bibliotheken zu pflegen
    • Unterstützung für Hardware-Terminals, die praktisch nicht mehr sinnvoll nutzbar sind, nicht mehr einzuschließen
    • von Betriebssystemen bereitgestellte terminfo-Dateien und das terminfo-Dateiformat weiterhin zu unterstützen, aber ein Protokoll einzuführen, mit dem sich feststellen lässt, welche Informationen aktueller sind
    • ein optionales TERMVERSION, um Funktionsunterschiede zwischen etwa Konsole 2022 und Konsole 2023 zu unterscheiden
    • moderne Funktionen wie 24-Bit-Farben, 256-Farben-Palettenanimation, URL-Links und das Kitty-Grafikprotokoll eindeutig auszudrücken
  • Auch ein abwärtskompatibler Weg für Legacy-Programme wäre möglich
    • ein in .bashrc ausgeführtes Programm könnte anhand von TERM und TERMVERSION binäre terminfo-Dateien unter $HOME/.terminfo/ erzeugen
    • dabei ließen sich eindeutige 24-Bit-Fähigkeiten wie RGB, setf24 und setb24 generieren
    • bei Programmen ohne RGB-Unterstützung könnte man annehmen, dass sie von einer 256-Farben-Palette ausgehen, und colors#0x100, initc und oc beibehalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-31
Hacker-News-Kommentare

  • Sich durch terminfo zu wühlen, fühlt sich an, als würde man in tiefen Katakomben mit einer flackernden Fackel Hieroglyphen anleuchten.
    Wenn man bedenkt, wie viel Komplexität in einer einzigen Terminal-App steckt, ist das schon merkwürdig – und macht einen noch dankbarer für Terminal-Entwickler wie die von iTerm und Kitty.
    Ich habe Funktionen gesammelt, die in iTerm+zsh die Tab-Farbe setzen: https://gist.github.com/aclarknexient/84ebe33c1879f921685304...
    Verglichen mit der früheren Art, sich per telnet mit HTTP oder SMTP zu verbinden: Der Text selbst ist zwar simpel, aber die Seite, die diesen Text darstellt, ist eine komplexe Anwendung, die alle möglichen Funktionen unterstützt.

    • Bei meinem selbstgebauten Terminal habe ich anfangs beschlossen, terminfo zu ignorieren und so zu tun, als wäre es rxvt; die daraus entstehenden Probleme nehme ich in Kauf.
      Das ist im Moment nur möglich, weil ich praktisch der einzige Nutzer dieses Terminals bin, aber moderne Terminals unterstützen einen recht großen gemeinsamen Teilbereich, sodass es weniger schmerzhaft ist, als wenn Apps einen unbekannten TERM-Wert nicht erkennen und durcheinandergeraten.
      Wenn man sich allerdings nicht häufig per SSH auf neue Systeme einloggt, ist das ein weniger wichtiges Problem.
    • Es wäre schön, wenn du einen Screenshot teilen könntest, auf dem die Tab-Farbe tatsächlich angewendet ist.
    • Die Software, die ich auf dem Mac am meisten vermisse, ist iTerm.
      Es ist nicht der schnellste Terminal-Emulator, aber optisch ist es mit Abstand der beste.

  • Die 16-Farben-Palette in den verschiedenen Terminal-Apps anzupassen, war einfacher, als den Terminal-Code auf Anwendungsseite exakt hinzubekommen.
    In ~/.Xdefaults setze ich die Farben für rxvt-unicode, und im Emacs-Theme .el wähle ich je nachdem, ob eine grafische Anzeige vorhanden ist, unterschiedliche Farbnamen und wende sie dann auf verschiedene Faces an.
    Als Bonus sieht auch die farbige Ausgabe von ls besser aus. Die standardmäßige 16-Farben-Palette ist oft viel zu stark gesättigt und hat schlechten Kontrast.

    • Genau (if (display-graphic-p) ist der entscheidende Punkt.
      Emacs unterstützt echte Grafikausgabe; unter X11/Cocoa/Win32 funktioniert Esc wirklich als Esc, außerdem sind Ctrl+Shift- oder Cmd-Bindings, die gleichzeitige Nutzung mehrerer Schriften, Bildanzeige, Änderungen der Cursorform usw. möglich.
      Es ist wie eine Zeitmaschine, die einen 20 Jahre nach vorn ins Jahr 1989 bringt.
    • Bei alten TTL-Displays war mehr nicht möglich, deshalb waren die Farben so stark gesättigt.
      Eine rote Leitung war entweder kräftig rot oder aus, und wenn eine Intensity-Leitung dazukam, wurde daraus 100 % Rot.
    • Wenn man Sequenzen in DIRCOLORS einfügt, unterstützt auch ls tatsächlich 24-Bit-Farben.
    • Ich habe ebenfalls die 16-Farben-Palette von Terminology in der INI-Datei an mein bevorzugtes Theme angepasst, sodass ich in der Konsole und in Terminal-Apps (vim) denselben Stil verwende.
    • Ich nutze fast denselben Ansatz.
      Die Standardfarben sind im Vergleich zum dunklen Hintergrund zu dunkel, deshalb habe ich die Luminanz aller Farben angehoben.

  • Hätte der Autor export COLORTERM=truecolor gekannt, hätte er es vermutlich deutlich leichter gehabt.
    Es taucht auch in der Fußnote zur Truecolor-Erkennung der verlinkten Emacs-Dokumentation auf und ist im Konsole-Screenshot zu sehen, könnte aber in mehreren Schichten von Terminal-Multiplexern verschwunden sein.
    Wenn dieser Wert gesetzt ist, versteht die App sofort, dass sie Truecolor verwenden soll; damit kann man den schwierigen Teil überspringen, und eine terminfo-Datenbank ist ebenfalls nicht nötig.

    • Stimmt. In diese Geschichte hätten auch Irrwege wie COLORTERM und die terminfo-Fähigkeit RGB gehört.
      Allerdings respektieren nicht alle Programme COLORTERM, deshalb hatte ich in meiner .bashrc früher bei linux | screen* COLORTERM unset gesetzt und ansonsten COLORTERM=truecolor exportiert.
      Heutzutage unterstützt Screen 24-Bit-Farben, also war das vermutlich eine Einstellung aus Ubuntu-18-Zeiten.
    • Oder man verwendet den bevorzugten GUI-Emacs zusammen mit tramp oder sshfs.
    • Stimmt. Wenn man den terminfo-Weg einschlägt, wartet nur der Wahnsinn.
      Andererseits liegt es auch daran, dass die ncurses-Maintainer recht konservativ sind und neue Terminal-Entwickler schnell vorankommen wollen.
    • Dass die terminfo-Datenbank nicht mehr nötig ist, gilt erst ab Emacs 28.
      Bei älteren Emacs-Versionen braucht man weiterhin die terminfo-Datenbank.
    • COLORTERM ist auch ziemlich seltsam.
      Meistens muss man es gar nicht definieren, aber wenn in einer screen-Session COLORTERM=truecolor gesetzt ist, sieht der Bildschirm plötzlich völlig kaputt aus; löscht man die Umgebungsvariable, wirkt alles wieder normal.

  • Für die Interaktion mit Emacs muss man nicht zwingend ein Terminal verwenden
    Für macOS, Windows, X.org und Wayland kann man grafische Frontends nutzen
    Grafisches Emacs sieht bei deaktivierter Toolbar dem im Terminal laufenden Emacs so ähnlich, dass Leute, die Emacs nicht kennen, ein grafisches Emacs-Fenster auf dem Rechner eines Kollegen leicht für ein Terminalfenster halten
    In einer Umfrage unter Emacs-Nutzern gaben 80 % an, ein grafisches Frontend zu verwenden

    • Als Gegenargument: Wenn man ein Terminal ohne die Schwerfälligkeit einer vollständigen GUI nutzen möchte, bekommt man allein mit xterm-mouse-mode schon 80 % der Vorteile
      Mit mouse, xterm-mouse-mode, mouse-wheel-mode, Scroll-Einstellungen usw. wird es ziemlich brauchbar, und auto-save-default lässt man, wie Gott es wollte, auf nil
    • Man lässt Emacs nicht in einem Terminalemulator laufen. Emacs ist der Terminalemulator
      Alle Terminalprogramme werden in shell-mode-Buffern von grafischem Emacs ausgeführt; nur für die seltenen Programme, die Vollbildsteuerung brauchen, nutzt man term-mode
      Es ist weder am funktionsreichsten noch am schnellsten, aber man kann sich darin wie in anderen Buffern bewegen und es nahtlos zusammen mit dem bearbeiten, woran man gerade arbeitet
      Wenn man auf einem entfernten Rechner kein grafisches Emacs starten kann, bearbeitet man Remote-Dateien mit tramp oder startet einen headless Emacs-Server und verbindet sich mit einem grafischen emacsclient
    • Guter Hinweis
      Ich hatte nie bedacht, dass Leute denken könnten, ich würde Emacs im Terminal laufen lassen
      Grafisches Emacs ist deutlich besser, aber dass es im Terminal zu etwa 90 % genauso funktioniert und aussieht, ist trotzdem großartig
    • Ich nutze X-basiertes Emacs, und das Protokoll ist effizient
      Es fühlt sich so leichtgewichtig an wie ein Terminal und nicht wie VNC
      Es bietet Vorteile wie Fonts, die gleichzeitige Nutzung unterschiedlicher Fonts, Menüs, Maus, Farben und mehrere Frames/Fenster
      Wenn die Grafik lokal läuft und man per tramp auf Remote-Systeme zugreift, kann man praktisch sogar Konfigurationsdateien auf einem entfernten Linux-basierten Router mit kaum mehr als busybox mit allen möglichen Komfortfunktionen bearbeiten
    • Am Ende gibt es zwei Gründe, warum ich immer wieder zu terminalbasiertem Emacs zurückkehre
      Ich nutze X11 seit den 90ern sporadisch, aber bei Fonts bin ich immer noch auf dem Niveau, dass ich suche, zufällig einen funktionierenden Befehl finde und ihn dann unverändert lasse
      Die Darstellungsleistung der meisten Terminalprogramme ist immer noch spürbar schneller als die von X11-Setups, die man in Unternehmensumgebungen verwendet

  • Heutzutage reicht es, ein aktuelles Emacs zu installieren, ein Terminal mit Unterstützung für 24-Bit-xterm zu öffnen und dann emacs -nw auszuführen
    Wenn es nach dem Anwenden eines Themes gut aussieht, ist man fertig; andernfalls fügt man in .bashrc, .zshrc, .fishrc usw. export COLORTERM=truecolor hinzu, lädt die Shell neu oder führt nur diese Zeile aus und startet emacs -nw neu
    Dieser Artikel lässt es so wirken, als müsste man sich in terminfo einarbeiten, aber normalerweise ist das nicht nötig. Vor zehn Jahren vielleicht, heute nicht mehr
    Ich habe es kurz noch einmal mit iTerm unter macOS sowie Alacritty, Kitty und Gnome Terminal unter Linux geprüft; Unterstützung für 24-Bit-xterm ist heutzutage weit verbreitet

  • Heute habe ich gelernt, dass auch in der Windows-10-Eingabeaufforderung standardmäßige ANSI-Escape-Sequenzen funktionieren
    24-Bit-Farben funktionieren ebenfalls gut
    Wenn man echo ^[[48;2;255;0;0mHello^[[0m ausführt, wird Hello mit rotem RGB(255,0,0)-Hintergrund ausgegeben, und ^[[0m setzt die Farbe wieder zurück
    ^[ muss mit CTRL-[ eingegeben werden; man darf ^ und [ nicht getrennt tippen

    • Wenn man nicht druckbare Zeichen nicht direkt in die Befehlszeile einfügen möchte, kann man zusammen mit einem Befehl, der Escape-Codes akzeptiert, den Escape-Code \x1b oder den Alias \e verwenden
      Zum Beispiel geht echo -e '\e[48;2;255;0;0mHello\e[0m'
      In Skripten ist echo -e allerdings nicht standardisiert, und auch normales echo verhält sich in Randfällen unterschiedlich; deshalb ist es besser, immer printf '\e[48;2;255;0;0mHello\e[0m\n' zu verwenden
    • Man darf nicht vergessen, in der Datei C:\CONFIG.SYS DEVICE=C:\DOS\ANSI.SYS hinzuzufügen

  • Der größte Vorteil von Emacs gegenüber vim/neovim ist, dass es nicht nur einen Terminalemulator in einem Fenster gibt, sondern erstklassige GUI-Unterstützung
    Ich weiß, dass es gVim und zahlreiche halbherzige neovim-Frontends gibt, aber die standardmäßige Ausführungsweise von Emacs ist eine echte GUI, und genau das gefällt mir
    Terminals sind auch in Ordnung, aber sie haben zu viel historischen Ballast und zu viele Einschränkungen, und vieles daran ergibt in der heutigen Zeit keinen Sinn mehr
    Wenn es ein Problem ist, Emacs auf einem Remote-Server auszuführen, gibt es TRAMP und emacsclient

    • Das Gute daran, alles im Terminal auszuführen, ist, dass man alles kopieren kann, was im Terminal angezeigt wird
      Es ist frustrierend, wenn eine GUI-App verhindert, dass man den angezeigten Text kopiert, sodass man ihn von Hand erneut eingeben muss
    • Das stimmt nicht. Neovim hat viele native Frontends und wurde überhaupt erst so entworfen, dass eine solche Struktur möglich ist
      https://github.com/neovim/neovim/wiki/Related-projects#gui
    • Stimme vollkommen zu
      Ich mag modales Editieren und vim wirklich sehr, aber die halbherzigen Lösungen von Terminal-Editoren waren schwer zu ertragen
      Wenn es reichhaltige grafische Plattformen gibt, warum sollte man sie nicht nutzen?
    • Es hängt stark vom Workflow ab
      Zum Beispiel nutze ich vim fast nur zum Bearbeiten von Dateien; für externe Tools wie git, Linter, Formatter, Debugger und Dateibaum-Operationen gehe ich zurück in die Shell
      Deshalb ist meine Hauptanwendung ohnehin schon der Terminalemulator, und in diesem Workflow fällt es kaum ins Gewicht, dass es keine dedizierte GUI gibt

  • Ich wünschte eher, mein Emacs sähe so aus: https://imgur.com/a/h0jA1ro
    Nicht ernst gemeint, nur ein Witz. Cool Retro Term benutze ich nur bei Präsentationen.
    Wie ich sehe, funktionieren 24-Bit-Farben in meinem Emacs standardmäßig: https://imgur.com/a/BM5OTxp
    Nur das Syntax-Highlighting nervt etwas.

    • https://muppetlabs.com/~mikeh/crt_emacs.png
      Cool Retro Term ist großartig, und ich würde es auch gern mal in einer Präsentation verwenden.
    • Ich mag Cool Retro Term wirklich sehr, aber es ist schade, dass das Projekt nahezu liegen geblieben ist und es unter MacOS mehrere Probleme gibt.
      Persönlich finde ich, dass andere Retro-Terminals nicht annähernd so gut aussehen.
    • Ich nutze tatsächlich einen leicht angepassten CRT-Effekt im Windows Terminal.

  • Es ist wirklich beschämend, Standards hinter so hohen Preisen wegzusperren.
    Die Leute müssen solche Umwege gehen, um sie nicht kaufen zu müssen, und so etwas kann dabei herauskommen.
    Ein Standard sollte zugänglich sein. In Zeiten, als es Standards nur als Bücher gab, mag es sinnvoll gewesen sein, die Druckkosten zu verlangen, aber dass ein lausiges PDF 200 Dollar gekostet hat, ist schwer zu glauben.

  • Ich habe den 24-Bit-Farbpatch für xterm geschrieben, aber erst heute erfahren, wie man ncurses mit xterm-direct zum Laufen bringt.
    Ich hatte zwar bereits meine eigene in Lisp geschriebene Terminal-Bibliothek im Einsatz, aber es ist trotzdem nützlich, einen Ersatzpfad über ncurses haben zu können.
    Danke an Mr. Dickey für die Antwort auf die Stack-Overflow-Frage und an Chad dafür, dass er das Thema angesprochen hat.