Schlechte Nachrichten, Emacs

• Es handelte sich um einen kritischen Beitrag zu Änderungen an der Register-Funktion in Emacs 30, doch der ursprüngliche Text ist in der derzeit öffentlich sichtbaren Fassung entfernt worden
• Der ursprüngliche Beitrag wurde gelöscht, weil er die jüngste Emacs-Entwicklung übermäßig kritisch behandelte und gegenüber den beteiligten Personen unfreundlich war
• Übrig geblieben ist nur der Hinweis, dass man im Git-Log der Website des Autors nachsehen soll, wenn man den gelöschten Inhalt einsehen möchte
• Der verbleibende Kernpunkt ist, dass der Autor begonnen hat, einen leicht abweichenden Branch von Emacs im Alltag zu verwenden
• Allein anhand des derzeit öffentlich sichtbaren Textes lassen sich die konkreten Änderungen oder technischen Streitpunkte rund um die Register-Funktion in Emacs 30 nur schwer nachvollziehen

---

Zurückgezogener kritischer Beitrag zu Emacs 30

• Der ursprüngliche Text behandelte Änderungen an der Register-Funktion von Emacs 30, die der Autor als Verschlechterung ansah
• In der öffentlichen Fassung ist als Grund für die Löschung vermerkt, dass der ursprüngliche Beitrag die jüngste Emacs-Entwicklung übermäßig kritisch darstellte und gegenüber den beteiligten Personen unfreundlich war
• Als weiterer Hintergrund für die Löschung wird erwähnt, dass der Beitrag deutlich mehr Aufmerksamkeit erhielt als frühere Blogposts

Derzeit verfügbare Informationen

• Wer den gelöschten Beitrag unbedingt lesen möchte, kann das Git-Log dieser Website prüfen
• Der Autor gibt an, begonnen zu haben, einen leicht abweichenden Branch von Emacs im Alltag zu verwenden
• Der derzeit öffentlich sichtbare Text enthält keine konkreten Probleme, Beispiele oder Patch-Details zu den Änderungen an der Register-Funktion in Emacs 30

[GN⁺]

Hacker-News-Meinungen

• Wenn im Entwicklungs-Branch von Emacs, ob beabsichtigt oder nicht, eine Breaking Change landet und einige Nutzer Bedenken äußern, läuft es nicht so, dass sie sofort zurückgenommen wird.
  Es braucht einen Prozess, in dem Vor- und Nachteile diskutiert, verschiedene Lösungen implementiert und verbessert und schließlich ein Kompromiss gefunden wird. Seit Nutzer ihre Bedenken geäußert haben, sind erst drei Tage vergangen; schwer zu sagen, dass dieser Prozess schon abgeschlossen sein müsste.
  Auch Elis jüngste Antwort lief darauf hinaus: „Die beiden Personen, die anfangs an der Diskussion beteiligt waren, hielten das neue Verhalten für deutlich sinnvoller als das alte; nun gibt es aber auch Gegenstimmen, also können wir das Verhalten weiter diskutieren und danach über den Default sprechen.“
  Ich denke, die Emacs-Entwicklung hat ernsthafte Probleme. Aber es ist ebenfalls ein Problem, wenn Nutzer sonst die störrischen Leute auf emacs-devel beschuldigen und dann, sobald eine Änderung kommt, die ihnen nicht gefällt, so tun, als ginge die Welt unter. Das macht Maintainer defensiv.

  • Es passt nicht, einen Aufstand zu machen, weil man den Entwicklungs-Branch nutzt und dort eine Breaking Change auftaucht. In einem Entwicklungs-Branch ist so etwas zu erwarten.
    Liest man den Mail-Thread, wirkt es eher wie starke Meinungsverschiedenheiten als wie „Arroganz“, und Konsens braucht nun einmal Zeit. Jemanden öffentlich als „arrogant“ zu bezeichnen, nur weil er nicht sofort auf die eigene Sichtweise einschwenkt, und dann eine Menge heranzuziehen, die den Thread ohnehin nicht lesen wird, wirkt beinahe wie Belästigung.
    Außerdem ist es nicht ehrlich zu sagen, der Patch, der die Änderung optional machen sollte, sei ignoriert worden. Dieser Patch fügte nicht nur eine Option hinzu, sondern entfernte auch weitere Änderungen; deshalb wurde er abgelehnt. Es ist auch schwer zu akzeptieren, die Verantwortung auf diese Weise einer einzelnen Person zuzuschieben.
  • Es wirkt widersprüchlich, einerseits zu sagen, „Nutzerreaktionen sind ein zentraler Input für die endgültige Entscheidung“, und andererseits negative Nutzerreaktionen als „übertrieben“ zu kritisieren.
    Hätten Nutzer nicht reagiert, wäre nach dem beschriebenen Verfahren sehr wahrscheinlich die ursprüngliche Änderung, gegen die sie waren, unverändert aufgenommen worden. Auch bei clojure-mode wollte rms den Namen eines Autors aus der Clojure-Community übernehmen und etwas neu schreiben, das lange gepflegt worden war; Leute protestierten auf der Liste und verhinderten es, mussten sich aber anhören, sie würden übertreiben. Deshalb wirkt die Kritik des „Übertreibens“ nicht besonders sinnvoll.
  • Das ist ein schlechter Prozess. Feature-Reviews sollten beginnen, bevor etwas in den Main-Branch gemergt wird, nicht danach.
    Wenn man ein Feature, das Nutzer-Workflows kaputtmacht, ohne Diskussion mit der breiteren Community in den Main-Branch bringt, ist es selbstverständlich, dass Leute wütend werden. Solche Merges sind die Art, wie alte Tools die Unterstützung ihrer Community verlieren.
  • Die Emacs-Community hat zumindest historisch sehr stark auf Abwärtskompatibilität geachtet. Bestehende Nutzer zu brechen, ist in Emacs so ziemlich eines der schlimmsten Dinge.
    Wenn man nicht ernsthaft in Erwägung zieht, eine Breaking Change sofort zurückzunehmen, ist das ein Signal, dass Emacs-Entwickler Abwärtskompatibilität nicht mehr so hoch schätzen wie früher; das hieße, einen erheblichen Teil der bestehenden Nutzer im Stich zu lassen.
    https://www.murilopereira.com/the-values-of-emacs-the-neovim...
    Kernwerte sind wichtig. Die Emacs-Maintainer haben gegen Kernwerte verstoßen, und es ist berechtigt, dass die Community verärgert ist.
  • Wenn die Darstellung im Artikel stimmt, mache ich mir Sorgen um den Zustand von Emacs. Schon vor dem Merge in master gab es Kontroversen, trotzdem wurde einfach gemergt.
    Dass man Nutzer-Workflows bricht, ohne es auch nur optional zu machen, und es nicht einmal opt-in, geschweige denn abschaltbar macht, wirkt wie eine achtlose Missachtung der User Experience.

• Wenn ich das richtig zusammenfasse, wurde kürzlich in Emacs ein Commit angenommen, der das Verhalten von Registern ändert – also etwas Allgemeineres als Kopieren.
  Emacs öffnet nun einen Minibuffer, der zeigt, was passiert, und man muss die Änderung mit Enter oder einer entsprechenden Eingabe bestätigen. Der Autor des ursprünglichen Beitrags sieht darin einen furchtbaren Kompatibilitätsbruch, weil das Standardverhalten geändert wird, sich womöglich nicht einfach per Einstellung abschalten lässt und es keine ausreichende Diskussion gab.
  Auf Vim übertragen wäre das so, als würde man "dyy eingeben, um die aktuelle Zeile in das Register d zu kopieren, woraufhin anschließend ein Scratch-Buffer geöffnet wird, der Text und Buffer anzeigt, und zum Schließen eine Tasteneingabe verlangt. Für normale Vim-Nutzer, die Register verstehen, wäre das furchtbar; es gibt allerdings auch Fälle, etwa Leute, die im visuellen Modus kopieren, in denen ein Verhalten bevorzugt wird, das „explizit zeigt, was kopiert wird“.
  Der Rest des Textes sagt, dass der ursprüngliche Autor versucht habe, eine Diskussion anzustoßen, der Commit-Autor Thierry dies aber verhindert habe und implizit auch der Rest der Emacs-Entwicklergemeinschaft Verantwortung trage.

  • Register sind eine vergleichsweise fortgeschrittene Funktion und werden vor allem für schnelles Editieren genutzt. Sie richten sich weniger an Erstnutzer mit Maus als an Leute, die komplexe Aufgaben schnell eintippen.
    Ich habe Emacs jahrzehntelang benutzt, bin aber nie tief in Register eingestiegen; persönlich habe ich zum Kopieren kill/yank verwendet und für komplexes Editieren Multiple Cursors oder einmalige Keyboard-Macros. Trotzdem hat Emacs viele optionale fortgeschrittene Editierfunktionen für Leute, die sich auf Muscle Memory verlassen wollen.
    Hier eine Bestätigungstaste hinzuzufügen, wirkt seltsam. Es ist ein bisschen so, als würde man an ein E-Piano ein „Pedal zur Bestätigung ungewöhnlicher Akkorde“ anbauen: Man legt einem schnellen, komplexen Eingabevorgang noch einen Schritt obendrauf.
    Emacs hat ein hervorragendes Undo; statt also zu fragen „Soll der Inhalt von Register d eingefügt werden?“, sollte es einfach einfügen und den Nutzer rückgängig machen lassen, falls er falsch gewählt hat.
    Deshalb ist es hier seltsam, die Kompatibilität zu brechen, und wenn es keine Möglichkeit zum Abschalten gibt, dürften viele Nutzer verärgert sein. Emacs ist ein Werkzeug, das älter ist als moderne GUI-Konventionen, und kann neuen Nutzern daher nicht so vertraut vorkommen wie vscodium; insofern ist auch das Argument plausibel, Power-User möglichst gut zu bedienen.
  • Für Leute, die Emacs nicht nutzen, sollte klargestellt werden, dass das normale Kopieren, kill-ring-save, standardmäßig M-w, nicht betroffen ist; geändert wird nur die fortgeschrittenere Funktion Speichern in Registern.
    Register sind keine Obermenge der Zwischenablage, also des Kill Rings.
    Außerdem scheinen Leute, die sagen, diese Änderung werde nicht konfigurierbar sein, die Anpassbarkeit von Emacs nicht gut zu kennen. „Einstellungen“ dienen nur der Bequemlichkeit; wenn man will, kann man den Code komplett ändern. Das ist der Elisp-Teil von Emacs, und selbst wenn es unverändert so hineinkommt, wird es innerhalb weniger Minuten ein Paket geben, das das Verhalten ändert. Dafür braucht es keinen Fork; die Rede von einem Fork ist hier allenfalls eine performative Geste.
  • Wenn diese Änderung in v30 kommt, wird das ziemlich nervig werden. Ich kenne Lisp überhaupt nicht, speichere aber ständig Dinge in Registern.
    Falls es nicht zurückgenommen wird, hoffe ich, ein Macro-Schnipsel zu finden, das die zusätzliche Tasteneingabe für mich übernimmt. Emacs braucht selbst für einfache Dinge ohnehin schon viele Tastendrücke, und ich bin nicht erfahren genug, um mir für diese Änderung selbst ein Macro zu bauen.
  • Als Zusammenfassung des Artikels ist das okay, aber wenn man die Mailingliste mitliest, reicht es als Zusammenfassung des Problems nicht aus.
    Die Sache scheint damit begonnen zu haben, dass Thierry mehrere Probleme im Register-Verhalten gefunden und beheben wollte.
    Der wichtigste Fehler war, dass nach C-x r SPC für save-to-register die nächste beliebige Taste dazu führte, dass Text in dem dieser Taste entsprechenden Register gespeichert wurde. Insbesondere funktionierte auch C-g, Emacs’ allgemeine Abbruchtaste, hier nicht, sondern speicherte Text oder eine Position in einem Register namens ^g. Wenn man versehentlich jump-to-register oder insert-register aufrief, konnte man nicht mit C-g oder Ähnlichem abbrechen, sondern musste zwingend ein Register auswählen.
    Zweitens können Register entweder Text, eine Position oder einen leeren Wert enthalten. jump-to-register funktioniert nur bei Registern mit Position, und insert-register erwartet Text. Emacs bietet beim Ausführen von Befehlen eine Vorschau nicht leerer Register an, unterschied dabei aber nicht – etwa wurden auch Register mit Strings als Kandidaten für jump-to-register angezeigt.
    Thierry wollte diese Probleme sowie Feedback aus dem Code-Review beheben, und die Reviewer hielten die Änderung für wichtig, auch wenn dadurch zusätzliche Interaktion entsteht. Den Kompatibilitätsbruch, dass man nach der allgemeinen Registerauswahl RET drücken muss oder eine zusätzliche Taste braucht, um in ein seltsames Register wie ^g zu speichern, sahen sie im Verhältnis zum Nutzen als vertretbar an.
    Der ursprüngliche Autor bat um einen Schalter zum Wechseln zwischen neuem und altem Verhalten und bekam als Antwort, er solle einen Patch einreichen; der eingereichte Patch nahm jedoch alle oben genannten Verbesserungen zurück und implementierte stattdessen über ein Flag eine völlig andere Funktion: „Bestätigung beim Überschreiben nicht leerer Register“. Thierry probierte ihn aus, gab kurzes Feedback, und der Autor antwortete im Grunde: „So etwas brauche ich nicht.“
    Als danach mehr Leute die Funktion nutzten, stellte sich heraus, dass Thierry und die ersten Reviewer mit ihrer Einschätzung falschlagen, die Auswirkungen der brechenden Änderung seien gering. Thierry begann daraufhin, ein Flag zu bauen, das die neuen Arbeiten beibehält, aber auch den alten Ablauf erlaubt. Insbesondere war das Entfernen des zusätzlichen RET nicht der Kern, sondern eher ein Nebeneffekt.
    Insgesamt scheint der Prozess ziemlich gut zu funktionieren, und eine Diskussion ohne Kontext mit der Anti-Hacker-Haltung „Wenn es irgendwie funktioniert, darf man es auf keine Weise ändern“ durchdrücken zu wollen, trifft eher auf den ursprünglichen Autor zu.
  • Als Vim-Anfänger hätte ich wohl erwartet, dass dyy bedeutet, die aktuelle Zeile zu löschen.
    Aber vielleicht ist genau das der Beweis, dass ich Anfänger bin.

• Wenn man sich diesen Mailinglisten-Thread ansieht, scheint eine Option zum Zurücksetzen dieses Verhaltens zu kommen: https://yhetil.org/emacs/[e-mail]/#t
  Diese Option scheint bereits erwähnt worden zu sein, bevor der ursprüngliche Beitrag veröffentlicht wurde, aber der Autor könnte sie übersehen haben. Das dürfte das Problem lösen, auch wenn ich vielleicht etwas übersehe.
  Änderung: Nach ginkos Antwort unten scheint weiterhin ein Druck auf RETURN nötig zu sein.

  • Trotzdem scheint ein zusätzliches RET nötig zu sein, wenn man das Überschreiben eines Registers bestätigen will.
    https://yhetil.org/emacs/[e-mail]/
  • Wenn man sich diesen Thread ansieht, wirkt register-use-previews wie ein Toggle für dieses Verhalten.
    Allerdings wird ein Bug erwähnt, bei dem selbst bei Einstellung auf never in bestimmten Workflows eine Bestätigung erscheint. Wenn es wirklich eine Option ist, dürfte das die meisten Bedenken ausräumen.

• In Emacs sollte Muscle Memory zu einem Anliegen erster Klasse erhoben werden

  • Vor einiger Zeit brachte ein Dateimanager, den ich mochte, eine neue Version heraus, in der die Keybindings geändert waren. Ich erinnere mich nicht einmal mehr an den Namen, aber die Wut, die ich damals empfand, ist mir so deutlich in Erinnerung geblieben, dass sie mir schon damals übertrieben vorkam
    Weil das aufgebaute Muscle Memory kaputtgemacht wurde. Bis ich mich beruhigt hatte, hatte ich ziemlich finstere Gedanken. Es mag wie eine Kleinigkeit wirken, aber ich kann verstehen, warum die Reaktion auf das Verbrechen des „Verrats am Muscle Memory“ bis zu „fork you“ eskaliert
  • Das betrifft nicht nur Emacs. Ich interessiere mich überhaupt nicht für Emacs, aber diese Geschichte ist wichtig, weil sie die Arroganz von Entwicklern zeigt, die etwas „verbessern“ wollen, ohne die stabilen Erwartungen der Leute zu berücksichtigen
    Das gilt für Google Maps oder iOS genauso wie für Emacs
  • Allgemeiner gesagt sollte häufig genutzte Software so gebaut sein, dass sie Muscle Memory ermöglicht, und spätere Versionen sollten das nicht ohne triftigen Grund brechen
    Muscle Memory ermöglicht es, Software „ohne Hinsehen“ halb-asynchron zu bedienen, ohne bei jeder kleinen Interaktion visuell nachzuprüfen. Leider gibt es bei Desktop-Software den Trend, Tastaturbedienung immer umständlicher zu machen oder gleich ganz unmöglich
  • Mindestens sollten Umstellungen, die Muscle Memory brechen, ein Toggle sein, dessen Standardwert „meine Einstellungen wie bisher beibehalten“ ist

• Es ist zwar ein guter Rant, aber dass nicht erklärt wird, um welche Funktion es eigentlich geht, hilft der Überzeugungskraft nicht
  Emacs-Register sind eine sehr alte Abstraktion. In Register kann man Werte hineinlegen und wieder herausholen, ähnlich wie bei separaten Zwischenablagen; es gibt 62, die an die zentralen ASCII-Zeichen [a-zA-Z0-9] gebunden sind, und sie bieten eine flexible und schnelle Tastaturschnittstelle. Man kann sogar interessante Dinge tun, etwa Tastaturmakros aus Registern ausführen. Manche nutzen sie viel, ich persönlich nicht
  Der Autor ist verärgert, weil die Standard-Bindings geändert wurden und sich nun eine modale UI vor einen Arbeitsablauf schiebt, der früher vollständig mit Tastatur und Home Row funktionierte. Das klingt nach einer nachvollziehbaren Beschwerde, und wenn eine in meinem Muscle Memory verankerte Funktion so geändert würde, wäre ich wohl auch genervt

  • Ich habe Emacs vor langer Zeit aufgegeben, verlasse mich aber stark auf den X11-Selection-Buffer, also Einfügen per Mittelklick, und kann das daher nachvollziehen
    Wenn zwischen jedem Auswählen und Einfügen ein modaler Bestätigungsdialog auftauchte und es keine Einstellung gäbe, um zum bisherigen Verhalten zurückzukehren, wäre ich definitiv sauer. Man könnte das bisherige Verhalten als Option implementieren. Buchstäblich ein paar Zeilen Code würden reichen
  • Es gibt mehr als 62 Register. Einer der Kritikpunkte ist, dass der Minibuffer beispielsweise den Zugriff auf das Register C-a kaputtmacht
    Ich kenne jemanden, der Buchstaben für Positionen und C-Buchstabe für Text verwendet. Für manche mag das ein sehr spezieller Fall sein, aber solche Leute dürften sehr wütend werden
  • Eli scheint das nicht als festes Standardverhalten zementieren zu wollen. Ich bin auch kein Fan davon
    Unter https://yhetil.org/emacs/[e-mail]/ sagt Eli: „Da es Einwände gab, diskutieren wir weiter, wie das Verhalten sein sollte, und wenn es eine Schlussfolgerung gibt, können wir über den Default sprechen“
  • Wenn man „Standard-Binding“ sagt, klingt das so, als könne man es anders konfigurieren. Geht das tatsächlich?
  • Es ist praktisch so, als hätte man einen globalen, nicht abschaltbaren uac-mode in allen Buffern aktiviert. Wenn das nicht stimmt, ist es etwas zum Weglachen

• Die Interpretation des ursprünglichen Autors ist nicht gut. Nutzer, die Stabilität wollen, sollten auf einem Release-Branch bleiben oder einen Commit auf master pinnen
  Man sollte erwarten, dass der Entwicklungs-Branch zur Entwicklung von Features in Arbeit genutzt wird, und solche Features können Zeit brauchen, bis sie ausgereift sind. Wer master folgt, wird häufig auf Breaking Changes stoßen, und wenn der eigene Workflow dadurch gestört wird, sollte man damit vertraut sein, zu einem früheren Commit zurückzugehen. Die bessere Wahl ist, bei Releases zu bleiben

• Der Kern von Emacs ist, dass es eine extrem anpassbare Plattform ist; wenn einem das Verhalten einer Funktion nicht gefällt, kann man es mit ein paar Zeilen Lisp selbst ändern
  Wegen einer Änderung an einem obskuren Feature das ganze Projekt zu forken, ergibt überhaupt keinen Sinn. Ich nutze Emacs seit etwa 1981, als es noch mit TECO-Makros implementiert war, aber Register nutze ich nicht

  • Um eine extrem anpassbare Plattform zu sein, muss die Plattform selbst sehr stabil sein
    Sonst müssen alle jedes Mal, wenn sich die Plattform ändert, sämtliche Anpassungen neu schreiben oder reparieren
  • Ich weiß nicht, was der Unterschied zwischen „selbst ändern“ und „forken“ sein soll
    Wenn dieser Patch so bleibt und jemand exakt die alte Arbeitsweise haben will, muss er faktisch in seinem lokalen Emacs-Repository einen Revert-Patch anwenden und seine eigenen Änderungen daraufsetzen. Jedes Mal, wenn sich upstream Emacs ändert, muss er rebasen, um neue Änderungen hereinzuholen
    Das ist ein privater Fork. Für immer geforkt und für immer am Rebasen
    Man könnte auch grob per Monkey Patch statt der ausgelieferten Datei oder danach eine eigene Datei laden und Funktionen neu definieren, aber auch das ist eine Art Fork. Man muss das Material irgendwo als Projekt aufbewahren und bereit sein, es anzupassen, wenn Änderungen den Monkey Patch brechen
  • Es scheint übersehen worden zu sein, dass diese Änderung keine Möglichkeit enthält, per Einstellung zum bisherigen Verhalten zurückzukehren

• Ich bin seit 20 Jahren weg von Emacs, aber ich verstehe, dass diese Änderung ziemlich disruptiv ist
  Was ich nicht verstehe: Emacs rühmt sich doch, „alles bis zur Küchenspüle“ dabei zu haben — warum wurde keine Option hinzugefügt, um zum bisherigen Verhalten zurückzukehren?

  • Vermutlich wird diese Option hinzugefügt. Der ursprüngliche Autor ist nur verärgert, weil sein Patch nicht akzeptiert wurde
    Dieser Patch fügte zwar ein Flag hinzu, entfernte aber auch alle anderen Verbesserungen

• Der Ton des Textes wirkt ziemlich „neckbeard“. Es ist ein extrem obskures Feature, das drei Nerds benutzen, keine unbewegliche Leiter der Grabeskirche
  Nur weil ein unbezahlter Maintainer es leicht geändert hat, ohne dich vorher zu fragen, heißt das nicht zwingend, dass er „master kaputtgemacht“ hat. Wir sprechen hier von master, nicht von einer Stable-Version oder einem getaggten Release

• Natürlich ist die einzig mögliche Lösung, einen weiteren Emacs-Fork oder eine Neuimplementierung zu versuchen
  Dieser hier wird ganz sicher Erfolg haben und nicht wie die anderen völlig irrelevant werden

  • Die Wirkung solcher Forks besteht darin, dass die Community um das Hauptprojekt allmählich erodiert
    Ob der Fork das Hauptprojekt an den Verhandlungstisch bringt, ist allerdings nicht besonders wichtig. Der ursprüngliche Autor hat die Fähigkeit und den Willen, diesen Patch dauerhaft in seinem lokalen Repository mitzuschleppen und zu pflegen. Was zur Vollendung des Forks fehlt, ist nur, dieses lokale Repository öffentlich zu machen
  • Allein anhand des Blogposts ist nicht klar, welche langfristigen Absichten der Autor mit dem Fork hat
    Vielleicht soll er auch nur dazu dienen, die Mainline-Maintainer zu überzeugen