In Emacs sieht alles wie ein Service aus

 (yummymelon.com)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Emacs ist weniger ein Betriebssystem an sich, sondern orchestriert Anwendungen und Utilities oberhalb des Kernels und wird durch Nutzung von Dateisystem, Netzwerk und externen Programmen zum Client für verschiedenste Services
  • Die für einen Client nötigen UI-, Kommunikations- und lokalen Datenspeicher-Schichten lassen sich mit eingebauten Bibliotheken wie Minibuffer, Buffers, URL, TCP/UDP, JSON und SQLite aufbauen
  • Die dynamische Sprache Emacs Lisp (Elisp) kann Elisp-Funktionen und Shell-Befehle zur Laufzeit kombinieren und so flexibel die Funktionen orchestrieren, auf die Emacs zugreifen kann
  • Der Beispielbefehl wttr nimmt einen Ort entgegen, sendet eine HTTP-Anfrage an wttr.in, extrahiert Region, Temperatur und Wetter aus JSON, zeigt das Ergebnis im Minibuffer an und speichert es außerdem im Kill Ring
  • Das vollständige wttr.el umfasst nach cloc 67 Zeilen; wenn Netzwerkaufrufe und JSON-Verarbeitung an Kommandozeilentools wie Python ausgelagert werden, lässt sich sogar ein noch kürzerer Elisp-Client bauen, der den Shell-Befehl selbst als Service nutzt

Emacs orchestriert Services oberhalb des Betriebssystems

  • Emacs als Betriebssystem zu bezeichnen, ist nicht ganz korrekt; der Vergleich entsteht aber durch seine Fähigkeit, Anwendungen und Utilities oberhalb des Betriebssystem-Kernels zu orchestrieren
  • Da Emacs mit eingebauten Funktionen auf Betriebssystem-Services wie Dateisystem und Netzwerk zugreifen und auch andere Programme ausführen kann, lässt sich Client-Verhalten innerhalb von Emacs leicht ad hoc zusammensetzen
  • Weil sich viele Computing-Aufgaben über verschiedene Client-Modi erledigen lassen, ist auch die Vorstellung plausibel, dass Nutzer „nur in Emacs leben“

Das Client-Server-Modell anhand von Anfrage und Antwort

  • Das Client-Server-Modell ist ein Interaktionsmuster, bei dem Services, die Ressourcen bereitstellen, und Clients, die diese anfordern, die Arbeit aufteilen
    • Der Client sendet eine Anfrage
    • Der Server verarbeitet die Anfrage und gibt anschließend eine Antwort zurück
  • Transaktionen aus Anfrage und Antwort können über ein Netzwerk oder lokal innerhalb eines Systems ausgeführt werden
  • Das netzwerkbasierte Modell hat sich in der REST-Softwarearchitektur breit weiterentwickelt

Drei Bereiche eines Emacs-Clients

  • Ein typischer Client ist für drei Bereiche zuständig
    • UI: Verarbeitet je nach Bedarf Nutzereingaben und Ausgaben
    • Client Edge: Kommuniziert mit dem Service; bei Netzwerk-Clients übernimmt das Netzwerksubsystem diese Rolle
    • Lokale Datenbank: Repräsentiert Daten, die mit dem Server ausgetauscht oder synchronisiert werden; die konkrete Verwaltung hängt von den Anforderungen der Implementierung ab

  • Aufbau der Benutzeroberfläche

  • Service-Kommunikation und Datentransformation

    • Für den mit dem Service verbundenen Client Edge lassen sich folgende Funktionen nutzen
    • Für Serialisierung und Deserialisierung nutzt man eingebaute Parser

  • Lokale Datenverwaltung

    • Für lokale Repräsentationen von Serverdaten können Elisp-Collections genutzt werden
    • Wenn persistenter lokaler Speicher nötig ist, kann SQLite verwendet werden
    • Die Komplexität eines realen Clients hängt von den Anforderungen ab; wenn es bereits ein bestehendes Kommandozeilen-Utility für schwere Verarbeitung gibt, lässt es sich als per Shell-Aufruf erreichbarer Service neu einordnen

Funktionen mit Elisp kombinieren

  • Auf alle zuvor genannten Bibliotheken kann aus Emacs Lisp (Elisp) zugegriffen werden
  • Elisp ist eine dynamische Programmiersprache, die zur Laufzeit ein hohes Maß an spontaner Komposition erlaubt
  • Von Elisp-Funktionen bis zu Shell-Befehlen lassen sich Aktionen kombinieren, die Emacs nutzen kann, um komplexe Abläufe zu orchestrieren

Implementierung eines Wetter-Clients für wttr.in

  • wttr.in ist ein konsolenorientierter Webservice für Wettervorhersagen und unterstützt JSON-Ausgabe
  • Der Emacs-Befehl wttr arbeitet in dieser Reihenfolge
    1. Er fragt den Nutzer nach einem Ort
    2. Er erzeugt die Anfrage-URL für wttr.in
    3. Er sendet die HTTP-Anfrage
    4. Er verarbeitet die JSON-Antwort
    5. Er zeigt das Ergebnis im Minibuffer an und speichert es im Kill Ring
    6. Falls bei der Verarbeitung ein Fehler auftritt, zeigt er im Minibuffer eine Fehlermeldung an

  • Anfrage-URL erstellen

    • wttr--request-url verwendet https://wttr.in als Basis-URL
    • Es ersetzt Leerzeichen im eingegebenen Ort durch + und erzeugt eine Query der Form /<location>?0&format=j1
    • Die fertige URL wird anschließend an die JSON-Abruffunktion übergeben

  • HTTP-Anfrage und JSON-Parsing

    • fetch-json-as-hash-table ruft die URL synchron mit url-retrieve-synchronously ab
    • Wenn keine Daten empfangen werden, löst es den Fehler Failed to fetch data from <URL> aus
    • Im Antwort-Buffer springt es hinter die HTTP-Metadaten-Header und wandelt den restlichen Inhalt anschließend mit json-parse-buffer in eine Elisp-hash-table um
    • Nach der Verarbeitung wird der heruntergeladene Netzwerk-Buffer immer entfernt, um Speicherlecks zu vermeiden

  • Wettermeldung zusammensetzen

    • wttr--report-message extrahiert die folgenden Werte aus den JSON-Daten
      • Name des nächstgelegenen Orts
      • Region
      • Land
      • Aktuelle Temperatur in Grad Celsius temp_C
      • Aktuelle Temperatur in Grad Fahrenheit temp_F
      • Wetterbeschreibung weatherDesc
    • Nicht leere Ortselemente werden mit Kommas verbunden, und daraus wird ein Ergebnis im Format Ort: Celsius, Fahrenheit Wetterbeschreibung gebildet
    • Die vollständige Implementierung ist im wttr.el-Quellcode zu finden

Auch Kommandozeilentools als Service nutzen

  • Die Emacs-API bietet Abstraktionen auf hohem Niveau; selbst wttr.el, das HTTP-Anfragen und JSON-Verarbeitung direkt implementiert, umfasst nach cloc nur 67 Zeilen
  • Eine noch einfachere Alternative besteht darin, die eigentliche Netzwerkanfrage und JSON-Verarbeitung einem Python-Skript namens weather zu überlassen
    • Der Elisp-Befehl weather fragt den Nutzer nach einem Ort
    • Er baut mit dem Ort als Argument den Shell-Befehl weather zusammen
    • Er führt den Befehl mit shell-command-to-string aus
    • Er speichert das zurückgegebene Ergebnis im Kill Ring und zeigt es im Minibuffer an
  • In dieser Konstellation wird der Shell-Befehl zum Service, der Anfragen entgegennimmt, und die Elisp-Funktion übernimmt die Rolle des Clients
  • Dank der dynamischen Eigenschaften von Elisp lassen sich Elisp-Bibliotheken und Kommandozeilen-Utilities je nach Bedarf kombinieren; diese Integrationsfähigkeit macht es möglich, innerhalb von Emacs alles wie einen Service zu behandeln

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Hacker News

  • Emacs wirkt nur deshalb wie ein Betriebssystem, weil sich die Familie der Lisp Machines nie im Mainstream durchgesetzt hat
    „Symbolics Lisp Machine demo“
    https://www.youtube.com/watch?v=o4-YnLpLgtk
    „Emacs and Lisp“
    https://funcall.blogspot.com/2025/04/emacs-and-lisp.html
    Lucid fork­te Emacs zu XEmacs, um eine der frühen LSP-Ideen umzusetzen; die meisten Funktionen von damals sind inzwischen wieder in Emacs integriert
    https://dreamsongs.com/Cadillac.html
    „Lucid Energize Demo“
    https://www.youtube.com/watch?v=pQQTScuApWk

    • Ein Betriebssystem ist eine virtuelle Maschine, die dafür gemacht ist, von mehreren Programmen gemeinsam genutzt zu werden. Normalerweise legt es den Großteil der Befehlssatzarchitektur (ISA) offen, auf der es läuft, aber es gibt auch Ausnahmen wie Inferno, Taos oder AS/400
    • Selbst wenn LISP-Maschinen erfolgreich gewesen wären, würde ein darauf laufender Editor nicht zum Betriebssystem. Wenn man Plattform und Betriebssystem verwechselt, könnte man auch Webbrowser oder sogar Roblox als Betriebssystem bezeichnen

  • Wenn man client, server und request weit genug definiert, lässt sich alles in eine Client/Server-Architektur pressen. Das erinnert an die bemühte Behauptung, Emacs folge der Unix-Philosophie, nur weil eine LISP-Funktion eine Sache gut erledigt
    Dass Emacs Ideen der LISP-Maschine folgt, ist wohl weitgehend unstrittig, und darauf lässt sich praktisch alles implementieren, was man möchte. Es integriert sich hervorragend mit CLI-Tools, aber unklar ist, was man gewinnt, wenn man das als Client/Server definiert
    Über Jahrzehnte hat Emacs verschiedenste Trends durchlaufen und Funktionen absorbiert; intern gibt es sogar noch die heute kaum genutzte CEDET-Semantikanalyse-Engine. Danach kam LSP auf, und nun ist die Ära der Agenten angebrochen; auch als Frontend für Agenten ist Emacs ziemlich gut geeignet

    • Emacs ist ein LISP-Flüchtling, der in der Unix-Welt Zuflucht gefunden hat. Es folgt nicht der Unix-Philosophie, sondern der LISP-Philosophie, integriert sich aber gut in Unix
    • Früher war es üblich, dass die meisten IDEs eigene Semantikanalyse-Engines hatten. Soweit ich mich erinnere, wurde auch der erste Java-Language-Server aus der Java-Semantikanalyse-Engine von Eclipse herausgelöst

  • Ich habe Emacs über 25 Jahre lang genutzt, aber in der Firma, zu der ich letztes Jahr gewechselt bin, darf ich Emacs nicht einmal für Aufgaben verwenden, für die es besonders gut passt. Die Begründung war, dass alle Teammitglieder dieselben Werkzeuge nutzen müssten, und es ist mir nicht gelungen, die anderen zu Emacs zu bewegen
    Jetzt verwende ich für jede Aufgabe separate Single-Purpose-Tools, deutlich ineffizienter, und lerne ständig neue UIs und Tastaturbelegungen

    • Mit dem Wachstum des Unternehmens wurde begonnen, installierte Software zu kontrollieren; offenbar werden erlaubte und blockierte Installationen mit Microsoft Intune verwaltet. Aus Sorge, Emacs nicht mehr nutzen zu können, schiebe ich sogar Laptop-Updates oder einen Austausch auf
      Der Administrator wird vermutlich sagen, dass alle in neuen Projekten Visual Studio Code verwenden sollen, aber das verwendete Consumption-Modell wird nicht einmal von VSCode unterstützt. Solange Git und der Deployment-Prozess passen, könnten alle den Editor wählen, mit dem sie gut arbeiten; vermutlich wird aber die Antwort kommen, Open Source ohne Microsoft-Support sei riskant und es handle sich um von der Firma nicht geprüfte Software
      Emacs ist mein zentrales Werkzeug im Alltag; wenn es verboten wird, werde ich kündigen. Der Administrator versucht nicht, das zu verstehen oder logisch zu beurteilen, sondern folgt nur den Vorgaben einer anderen IT-Abteilung
    • Wäre es auch vertretbar, allen Teammitgliedern telnet vorzuschreiben und ssh zu verbieten? Wichtig ist, nicht um Erlaubnis für die Emacs-Nutzung zu fragen, sondern es einfach zu verwenden
      Wenn die Firma einen allgemeinen Texteditor vorgibt, lohnt sich zu prüfen, ob selbst das Starten von Notepad ein Problem wäre und ob sie sogar persönliche To-do-Management-Tools festgelegt hat. Man kann eine Kategorie finden, in der Emacs etwas leisten kann und für die die Firma noch kein Werkzeug vorgegeben hat, und es dafür installieren
    • Das ist dieselbe Logik wie: Unterschiedliche Persönlichkeiten zu managen ist ineffizient, weil man jeden Menschen anders behandeln muss, also führt man bei allen Teammitgliedern eine Lobotomie durch
    • Wenn andere Werkzeuge ebenso viel Freiheit und Anpassbarkeit wie Emacs hätten, würden Emacs-Nutzer nicht versuchen, sämtliche Arbeit dort hineinzustopfen. Es geht nicht darum, dass Emacs grundsätzlich überlegen wäre, sondern dass andere Tools stärker eingeschränkt und schlechter selbstdokumentierend sind
    • Ich frage mich, warum die Behauptung, alle Teammitglieder müssten dasselbe Werkzeug verwenden, überhaupt plausibel sein soll

  • Emacs ist eine Plattform, und auch ein Betriebssystem ist nur eine von vielen Plattformen. Eine Plattform ist eine Softwareschicht, die dafür entworfen wurde, darauf Neues zu bauen; deshalb sollte man fragen, welche Plattform X für das Y geeignet ist, das man bauen möchte
    Für mich ist X oft Emacs, es könnte aber auch Racket oder Rust sein. Wenn ein Tool zugleich eine Anwendung und eine gute Plattform ist, lohnt sich dafür mehr Lernaufwand als für eine bloße Anwendung

  • Der Moment, in dem ich Emacs ausreichend genutzt hatte und die Aussage „Emacs ist ein Betriebssystem“ nicht mehr als Witz, sondern als tatsächlich glaubwürdiges Konzept verstand, war ein wichtiger Wendepunkt in meiner Laufbahn

    • Es gab bereits Betriebssysteme, und programmieren konnte man auch schon; fraglich ist, ob Emacs wirklich neue Fähigkeiten bereitgestellt hat. Emacs ist ein Texteditor, keine IDE und keine allgemeine Automatisierungs-Laufzeitumgebung; die Logik, dass MSPaint durch das Hinzufügen von Lisp plötzlich ein großartiges Werkzeug würde, ist schwer nachvollziehbar

  • Ich habe vor ein paar Jahren mit Emacs angefangen, um org mode auszuprobieren, und bin wegen der extrem hohen Flexibilität dabeigeblieben

    • Eine Zeit lang habe ich Spacemacs genutzt, aber jetzt habe ich ein Keychron G6 Pro, mit dem sich Caps Lock umprogrammieren lässt; nun will ich ernsthaft meine eigene init.el konfigurieren

  • Emacs ist eher eine Programmierumgebung mit eingebautem Texteditor. Wenn man es als etwas Ähnliches wie manche Smalltalk-Images betrachtet, ist es ein ziemlich interessantes Werkzeug

  • Emacs ist kein Betriebssystem, sondern eher eine Shell, wobei schon das Konzept einer Shell selbst nicht weithin verstanden wird

    • Wenn man eine Shell als Mittel versteht, andere Werkzeuge zu benutzen, ist vi sogar eher eine Shell. Viele Funktionen müssen nämlich per :.! an andere Standard-Unix-Programme delegiert werden
      Emacs dagegen enthält wie ein Betriebssystem alle möglichen Funktionen in einer einzigen riesigen Distribution

  • Ich habe kürzlich ein kurzes Einführungsvideo gefunden, das man gut Leuten zeigen kann, die Emacs nicht verwenden
    https://www.youtube.com/watch?v=mJZDmO5yOxE

    • Ich bin wirklich neugierig auf Anon Emooses init.el

  • Emacs selbst kann als Client und Server ausgeführt werden. Startet man den Server mit emacs --daemon und verbindet sich dann mit emacsclient, nutzen alle Terminal- und GUI-Instanzen denselben Server und teilen sich geöffnete Dateien und Buffer
    Leider funktionierte das nur lokal; ich habe versucht, den Emacs-Server-Socket per ssh weiterzuleiten und mich von einem entfernten Client aus zu verbinden, aber es ist fehlgeschlagen

    • Rückblickend war der Name emacsclient nicht gut gewählt. Wer 2026 zum ersten Mal mit Emacs in Berührung kommt, erwartet leicht, dass Client und Server ihren Ausführungszustand wie bei einem REST-Client über das Netzwerk synchronisieren
      Hier bedeuten Client und Server eine Unix Local Domain, also eine Struktur, bei der der Client über einen Dateisystem-Socket einfache Steuerbefehle sendet. Später kam auch Unterstützung für Netzwerk-Sockets hinzu, aber der Client sendet weiterhin nur einfache Steuerbefehle
    • Socket-Weiterleitung funktioniert zwar nicht, aber wenn man X11 nutzt, kann man mit ssh -X den Frame eines entfernten Emacs auf dem lokalen X-Server anzeigen. Bei Nicht-PGTK-GTK-Builds sollte man allerdings vorsichtig sein, weil der entfernte Emacs beim Schließen eines neuen Frames abstürzen kann
    • Ich frage mich, ob die Ursache für die fehlgeschlagene Socket-Weiterleitung überprüft wurde