Gibt es noch Menschen, die Emacs benutzen?
(jmmv.dev)- Nach dem Linux-Einstieg 1997 wechselte die Erfahrung zwischen Vim und Emacs ab, verlagerte sich 2015 zu VSCode und IntelliJ und führte 2022 in der Remote-Linux-VM-Umgebung von Snowflake mit Doom Emacs wieder zurück
- VSCode machte Lernen und Entwicklung durch eine moderne UI, geringe Größe, JSON-basierte Konfiguration und LSP-Integration für Go und Rust einfacher, und für Java-Entwicklung war IntelliJ die realistischere Wahl
- Auf Snowflakes alter Linux-VM drehte sich die Arbeit vor allem um shell scripts und Bazel-Build-Dateien; statt einer entfernten Grafikoberfläche passte SSH-basiertes Arbeiten besser, sodass Emacs wieder nötig wurde
- Doom Emacs lässt Emacs dank vernünftiger Standardeinstellungen, Sprachintegration, Vim-artiger Keybindings, eines Space-basierten Popup-Menüs und einer einfachen Struktur der Konfigurationsdateien wie eine IDE wirken
- Dass sich auf MacBook, Linux-Laptop, Linux-Cloud-Workstation und FreeBSD-Server überall nur mit shell, tmux und Emacs dieselbe Entwicklungsumgebung beibehalten lässt, ist der Hauptgrund, Emacs weiter zu benutzen
Von DOS/Windows-IDEs zum Linux-Editor
- Um 1997 begann der Einstieg in Linux mit Caldera OpenLinux 1.1
- Davor wurden vor allem Borland Turbo C++ und Visual Basic verwendet, daher bestand bereits Vertrautheit mit den ausgereiften IDEs jener Zeit
- Über zwei Linux-Einsteigerbücher kamen Vim und Emacs ins Spiel; beide Editoren wurden dort als fortgeschrittene Optionen vorgestellt
- Die zuvor genutzten IDEs wirkten vollständiger, trotzdem wurden die Grundlagen und Tutorials von Vim und Emacs jeweils erlernt
- Bis etwa 2015 wurden Vim und Emacs abwechselnd verwendet
- Emacs eignete sich besser für lange Coding-Sessions
- Vim war stärker, wenn wie bei pkgsrc-Arbeiten schnell zwischen vielen Dateien gewechselt und editiert werden musste
Warum der Wechsel zu VSCode und IntelliJ kam
- Vim und Emacs funktionierten zwar gut genug, aber die Sprachintegration war schwach, wodurch das Interesse an moderneren Editoren wuchs
- Mit dem Wechsel zu macOS wurden auch Atom und Brackets ausprobiert, doch Funktionen und Konfigurationsoptionen wirkten zu zahlreich, fragil und belastend
- VSCode, das 2015 erschien, fühlte sich von Anfang an wie ein passendes Werkzeug an
- Es wirkte modern und war vergleichsweise leichtgewichtig
- Der damalige Konfigurationseditor basierte auf JSON-Dateien statt auf einem Einstellungs-Panel, was als leichter kontrollierbar empfunden wurde
- Als das Lernen von Go und Rust begann, half die LSP-Integration von VSCode für die einzelnen Sprachen enorm
- Code-Autovervollständigung
- Fehlerhervorhebung in Echtzeit
- Höheres Lerntempo
- Bei der Arbeit an einem Java-Projekt mit Bazel bei Google war IntelliJ die natürliche Wahl
- Es gab auch Versuche, Java-Entwicklung mit Emacs zu betreiben, aber IntelliJ war so gut, dass es praktisch die realistische Wahl war
- Auch bei Microsoft, wo mit einer C++-Codebasis und entfernten Windows-Maschinen gearbeitet wurde, blieben VSCode und ein Vim-Plugin im Einsatz
- Viele arbeiteten per RDP direkt auf den entfernten Maschinen
- Bevorzugt wurde jedoch, VSCode lokal auf dem Desktop auszuführen und sich per SSH mit der entfernten Maschine zu verbinden
Der Auslöser für die Rückkehr zu Doom Emacs bei Snowflake
- Nach dem Wechsel zu Snowflake im Jahr 2022 fand die Entwicklung in einer alten Linux-VM statt, und der Arbeitsalltag bestand aus shell scripts und Bazel-Build-Dateien
- In dieser Umgebung lösten weder VSCode noch IntelliJ die eigentlichen Probleme, und die Einschränkungen entfernter Grafikoberflächen waren ebenfalls unerwünscht, sodass zur Verbindung per SSH mit einer lokalen VM zurückgekehrt wurde
- Für lange Arbeitssitzungen wurde wieder ein Editor gebraucht, und die Wahl fiel auf Emacs
- In der alten
init.elhatten sich über Jahre Hunderte Zeilen Konfiguration angesammelt, die nicht vollständig verstanden wurden; deshalb sollte alles verworfen und neu begonnen werden - An diesem Punkt kam Doom Emacs ins Spiel
- Doom Emacs ist eine von Anfang an konfigurierte „Distribution“ für Emacs
- Sie bietet vernünftige Standardeinstellungen
- Sie liefert vordefinierte Sprachintegrationen
- Sie bietet ehemaligen Vim-Nutzern eine vertraute Erfahrung
- Sie behauptet nicht, eine IDE zu sein, fühlt sich in der Praxis aber wie eine an
Wie Doom Emacs das Nutzungserlebnis verändert hat
- Nach der Einrichtung von Doom Emacs fühlte sich Emacs wieder wie 2015 VSCode als „das passende Werkzeug“ an
- Viele Emacs-Funktionen werden über Space-basierte Shortcuts und interaktive Popup-Menüs sichtbar und dadurch leichter auffindbar
- Neben Vim-artigen Keybindings ergibt sich ein Shortcut-Ablauf, der die Handgelenke weniger belastet
- Die Konfiguration ist auf drei einfache Dateien verteilt
config.el: legt globale Einstellungen wie theme und font festinit.el: wählt die zu aktivierenden Doom-spezifischen Module auspackages.el: installiert Pakete, die nicht in Doom enthalten sind
- Die Standardeinstellungen sind vernünftig, und die Details, die angepasst werden können, sind gut kommentiert
- Dank der Fortschritte bei LSP und moderner Funktionen wie tree-sitter fühlt sich Emacs inzwischen wie eine IDE an
- Für die meisten Sprachen, mit denen gearbeitet wird, gibt es nun eine ordentliche Sprachintegration
Der Wert derselben Entwicklungsumgebung überall
- Die stärkste Funktion ist, dass auf jeder Maschine dieselbe Entwicklungsumgebung verfügbar ist
- Zu den Arbeitsgeräten gehören ein MacBook, ein Linux-Laptop, eine Linux-Cloud-Workstation und ein persönlicher FreeBSD-Server
- Benötigt werden nur shell, tmux und Emacs
- Wer auf vielen unterschiedlichen Maschinen arbeitet, gewinnt durch dieselbe Umgebung und dasselbe Muscle Memory direkt an Produktivität
- Durch diesen Bedarf ist Emacs zu einem noch wichtigeren Werkzeug als früher geworden
Macht Doom Emacs zu viel?
- Es gibt Kritik, Doom Emacs mache „zu viel“, aber gerade das macht es in der Praxis nützlich
- Irgendwann stellt sich die Frage, ob die Konfiguration reduziert werden sollte, um Emacs selbst besser kennenzulernen
- Dass verschiedene moderne Third-Party-Module zunehmend in die Standardpakete von Emacs einfließen, verstärkt diese Überlegung noch
- In letzter Zeit besteht auch Interesse, Distributionen wie Bedrock oder Emacs Solo auszuprobieren
- Allerdings ist die dafür nötige Aktivierungsenergie hoch, und selbst wenn dieser Weg gewählt würde, käme am Ende wieder die Frage auf, warum nicht gleich bis zu „raw“ Emacs gegangen wird
Distanz zu Elisp, Org mode und Magit
- Wie Emacs auf Basis von Elisp die Workflows der Menschen so grundlegend verändert, ist noch immer nicht vollständig nachvollziehbar
- Zwar lässt sich innerhalb von Emacs mehr Logik und Workflow umsetzen, aber fast alles wird bereits bequem mit shell scripts erledigt
- Scripts fühlen sich aus der Perspektive „Unix is my IDE“ unixiger an
- Dass Org mode und Magit keine eigenständigen Anwendungen sind, sondern an Emacs gebunden bleiben, gefällt nicht
- Solange die Notwendigkeit besteht, weiter auf verschiedenen entfernten Maschinen zu arbeiten, bleibt Emacs dennoch ein wichtiges Werkzeug
1 Kommentare
Lobste.rs-Meinungen
Ich habe das geschrieben, weil das Thema einfach zu lustig ist
Nicht wegen einer bestimmten Frage, sondern weil ich dabei zusehe, wie Leute in hohen Positionen in Unternehmen durch CLI-basierte Coding-Agenten Kommandozeilen-Tools „entdecken“ und dann zeigen wollen, wie nützlich diese neue Entdeckung ist
Bisher ist tmux das Paradebeispiel, und ich warte schon darauf, dass ihnen bald auch auffällt, dass es Vim und Emacs gibt
Diese Werkzeuge sind schon seit Langem da, und wenn man die „fortgeschrittenen 10x-Entwickler“ im Unternehmen fragt, nutzen sie sie wahrscheinlich auch
Trotzdem wurden sie oft mit „Haha, das ist doch ein Relikt aus der Urzeit. Ab ins Web!!11“ abgetan. Vielleicht gab es ja einen Grund, warum diese Entwickler die Tools weiter benutzt haben ;P
Dazu gehört auch, dass die CLI verbreiteter wird und viel mündlich überliefertes Wissen dokumentiert wird. Natürlich nur unter der Voraussetzung, dass dieses Wissen von Menschen stammt
Hoffentlich bleibt dieser gute Teil auch nach der aktuellen unerquicklich schwierigen Phase erhalten
Ich gehöre auch zu denen, die gerade erst anfangen, es zu lernen
Vor ein paar Jahren habe ich Doom Emacs ausprobiert, bin aber wieder abgesprungen, weil es wegen der Latenz störend langsam war. Ich weiß nicht, ob das dank Native Compilation inzwischen Vergangenheit ist; mit einem völlig unkonfigurierten Standard-Emacs lässt sich das noch schwer einschätzen. Ich nutze 30.2 aus Nixpkgs, und es scheint so, als sei Native Compilation dort standardmäßig aktiviert
Dinge wie E-Mails in Emacs zu schreiben interessieren mich nicht besonders; ich brauche einen Editor, den ich nach meinen Vorstellungen formen kann. Schön wäre auch, wenn ich ihn später noch nutzen könnte, wenn ich Lisp lernen will; wahrscheinlich wird es Janet. In Helix gibt es mangels Plugins für Lisp kaum Auswahl. Mir gefällt auch die Philosophie „alles ist Text“, aber ob das in der Praxis wirklich zu mir passt, muss sich noch zeigen
Es kann auch einschüchternd sein, das erst 2026 zu lernen. Wegen des über Jahrzehnte angesammelten impliziten Wissens stolpert man beim Lesen über lauter Paketnamen, Befehlsnamen usw. und fühlt sich überfordert, obwohl man eigentlich nur
$THINGmachen will. Deshalb habe ich als geführten Lernpfad zu Mastering Emacs gegriffenAuch die Standard-Keybindings sind ziemlich seltsam. Ich weiß, dass man alles neu belegen kann, aber das ist wieder zusätzliche Arbeit. Dazu kommt, dass ich mir selbst eine geteilte ergonomische Tastatur gebaut und die Firmware auf einen Vim-/Helix-artigen Workflow abgestimmt habe, bei dem Modifikatortasten nicht im Zentrum stehen
Ich wechsle zwischen drei Geräten hin und her — MacBook Pro, PC und eine Custom-Tastatur —, also muss ich konsistente Keybindings finden, bei denen mir nicht das Gehirn schmilzt.
hjklliegt auf allen Tastaturen an derselben Stelle, Tasten wieCtrlaber nichtMan bekommt zwar manchmal die Standpauke zu hören, evil sei nur für Vim-Flüchtlinge, die das „wahre Evangelium von Emacs“ nicht lernen wollen, aber das wahre Evangelium von Emacs® besteht darin, es auf die Weise zu benutzen, die am besten zu einem passt
Ich nutze Emacs seit 1998 und war nie ein besonderer Vim-Fan. Um 2011 bekam ich leichte Probleme mit RSI im Handgelenk und probierte Pakete aus, die das lindern sollten; einige Jahre lang habe ich god mode viel genutzt, aber es fühlte sich weiterhin unbeholfen an
Dann habe ich evil ausprobiert — eigentlich nur, um „zu beweisen, dass es nicht funktionieren wird“, obwohl ich mein ganzes Leben lang nie Vim benutzt hatte —, und nach einer Woche war ich damit so sicher wie mit god mode, nach einem Monat sogar schneller als mit den offiziellen Emacs-Keybindings
Das heißt nicht, dass die Standard-Keybindings falsch sind. Meine Handgelenke sind nur nicht besonders gut, daher kann meine Erfahrung anders ausfallen. boon oder meow könnten ebenfalls gut passen
Wenn evil aber für dich funktioniert, musst du dich deswegen überhaupt nicht schuldig fühlen. Emacs verändert zwar manchmal den Nutzer, aber noch viel stärker verändert Emacs sich für den Nutzer
Am besten ist es, es selbst zusammenzustellen, aber das ist viel Arbeit, und Projekte wie Doom machen den Einstieg für neue Nutzer definitiv leichter
Früher kannte ich die Standard-Keybindings von Emacs ziemlich gut, aber natürlich haben sie sich für mich nie angefühlt, und vor allem waren sie schlecht auffindbar
Doom Emacs verwendet für fast alles einen SPC-Präfix-Key, und wenn man kurz innehält, erscheint ein temporäres Menü, das die möglichen Vervollständigungen erklärt — das ist ziemlich gut
So kann man Funktionen entdecken, die man vorher nicht kannte, und es kollidiert auch nicht mit dem modalen Vim-Modus
Deshalb fühlt sich eine Konfiguration wie ein guter Mittelweg an: Textbearbeitung im Vim-Modus, Emacs-Aufgaben über SPC-Kombinationen
Die Standard-Keybindings von Emacs haben aber auch Vorteile. Die grundlegenden Textmanipulations-Tasten werden mit readline und sogar mit macOS geteilt. Dass die Emacs-artigen Tasten zur Textbearbeitung unter macOS auch in VSCode übernommen wurden, ohne mit den Standard-Clipboard-Tasten zu kollidieren, machte VSCode unter macOS ziemlich angenehm
Nachdem ich zu Windows und Linux gewechselt bin, war VSCode ohne Vim-Plugin für mich kaum noch auszuhalten
Ich habe gehört, dass es Kakoune- und Helix-ähnliche Funktionen von Haus aus mitbringt und insgesamt weniger aufdringlich sein will. Ich habe beides nicht selbst benutzt, das basiert also auf Hörensagen
Beim empfohlenen evil-Paket sehe ich das Problem, dass es zu viele Keybindings an sich zieht und mit externen Paketen nicht besonders gut zusammenspielt, sodass man viele „Adapter“-Pakete braucht
meow war nach der einmaligen Einrichtung ziemlich pflegeleicht
Ich nutze es seit 33 Jahren, und es erledigt alles, was ich von einem Editor oder einer IDE brauche
Ich bin zwischen Doom und (n)vim hin- und hergewechselt und habe mich in letzter Zeit größtenteils bei Neovim eingependelt.
Das zentrale Problem, das ich mit Emacs hatte, war ausgerechnet, dass die Wartung schmerzhaft war. Wenn ich Doom aktualisierte, geriet die Paketsynchronisierung oft durcheinander, sodass als nukleare Option nur noch eine komplette Neuinstallation übrig blieb.
Klar, ich hätte das vielleicht auch auf eine weniger „anfängerhafte“ Weise beheben können, aber ab einem gewissen Punkt will man einfach nur noch, dass das Werkzeug funktioniert. Wenn man eigentlich etwas erledigen muss, dabei die Konfiguration kaputtgeht und man zu stark vom Editor abhängt, ist das schwer auszuhalten.
Trotzdem vermisse ich
org-modeund die allgemeine Art der Navigation in Emacs.Jedes Mal, wenn ich „moderne“ Lösungen wie VSCode oder CLion ausprobiere, stoße ich auf dieselben Probleme nur noch stärker. Es fehlen ordentliche Accessibility-Funktionen, sodass man statt reiner Tastaturnavigation unbeholfen klicken muss, und auch das „Vim“-Verhalten ist im Vergleich zum Original unvollständig.
Der Grund, warum ich heute Neovim benutze, ist einfach, dass es zuverlässig funktioniert. Ehrlich gesagt könnte ich über mein heutiges Emacs wohl dasselbe sagen, wenn ich einen Coding-Agenten nur zwei Minuten lang gebeten hätte, meine Konfiguration zu reparieren (:
update-Funktion von Doom ein paar Mal ausprobiert, aber es gab immer Probleme.Inzwischen lösche ich bei jedem Upgrade-Wunsch oder wenn es wegen eines Emacs-Upgrades nötig ist einfach mit
rm -rf ~/.emacs.d/alles und setze Doom von Grund auf neu auf.~/.doom.d/liegt bei mir unter Versionsverwaltung.Mit diesem Ablauf hatte ich keine Probleme.
Ich bin so ein Sonderling, der Emacs für Entwicklung, Schreiben und E-Mail nutzt, und das seit ungefähr 15 Jahren, aber Zeit oder Luft, um elisp zu lernen, habe ich letztlich nie gefunden.
Selbst wenn ich an Konfigurationsdateien herumspiele, weiß ich eigentlich nicht genau, was ich da tue. Dass es trotzdem immer noch meine produktivste Umgebung ist, zeigt nur, wie großartig dieser Editor ist :-)
Mastering Emacs steht schon peinlich lange auf meiner To-do-Liste, um es endlich richtig zu lesen.
M-x high-fiveBei mir ist es auch so, dass ich nur sehr wenige Pakete verwende und die Standard-Keybindings benutze. Eine high-five-Funktion gibt es zwar nicht, aber vielleicht grabe ich mich bei der Gelegenheit endlich mal in elisp ein.
Vor etwa zwei Jahren bin ich zu Emacs gewechselt, weil mir das Rendering von Vim nicht gefiel und ich Electron-/VSCode-artige Tools leid war.
avy und ein paar Jump-Plugins fand ich sofort großartig, aber was mich dauerhaft gehalten hat und was ich bis heute als Hauptwerkzeug für Codeänderungen nutze, ist magit.
Die Kundenunternehmen, mit denen ich beruflich zu tun habe, sind mit ihrem ganzen Geschäft auf die Nutzung sehr großer CSV-Dateien angewiesen, aber dort scheint niemand zu wissen, wie man Daten in einer 1GB-Datei öffnet oder prüft.
Sie kennen nicht einmal den Befehl
head, den man braucht, wenn man nach CSV-Headern fragt.Nach Jahren mit X/GUI bin ich gerade auf
-nwumgestiegen.Die Pgtk-Version nutze ich nur noch bei Präsentationen.