NEO Emacs: Ein Emacs-Neubau mit Rust und GPU

Rust statt C

Rust statt C ordnet eval-exec/neomacs in eine konkrete technische Aufgabe ein. NEO Emacs ist ein in Arbeit befindlicher Fork von Emacs, der von Eval Exec gestartet wurde. Die Kernidee des Projekts ist es, den C-Kern von Emacs in Rust neu zu implementieren und die Anzeige-Engine auf die GPU zu verlagern, w hrend die Kompatibilit t mit dem bestehenden Emacs- kosystem erhalten bleibt. Laut README ist das Projekt ausdr cklich eine Baustelle: raue Kanten, breaking changes und fehlende Funktionen sind zu erwarten, und Fehlerberichte sind willkommen. Das README stellt au erdem klar, dass NEO Emacs ein harter Fork von GNU Emacs ist, dessen Lisp-Baum mit emacs-31.0.90 synchronisiert wurde und dessen C-Kern vollst ndig durch Rust ersetzt wurde. Für eval-exec/neomacs ist dabei die Abgrenzung wichtig: Die README beschreibt diesen Punkt als Teil des Projekts, nennt aber keine zusätzlichen Leistungswerte. Wer den Code prüft, sollte genau den README-Einstieg und den Branch main heranziehen und die dort genannten Komponenten getrennt betrachten. Das verhindert, dass eine einzelne Funktion als Aussage über das gesamte Repository gelesen wird. Die veröffentlichten Angaben stammen aus der Projektbeschreibung und sind als solche einzuordnen.

GPU-Anzeige und Emacs-Modell

GPU-Anzeige und Emacs-Modell ordnet eval-exec/neomacs in eine konkrete technische Aufgabe ein. Das Projekt betrachtet Kompatibilit t als seinen zentralen Vertrag. Das README sagt, dass die init.el-Dateien, Pakete und die Muskelged chtnis der Benutzer weiterhin funktionieren sollen. Um das zu berpr fen, wird GNU Emacs selbst als Test-Oracle verwendet: Jedes neu geschriebene Subsystem wird daraufhin gepr ft, ob es sich identisch zu GNU Emacs verh lt. Reale Konfigurationen wie Doom Emacs dienen als t gliches Testbett. Die Statustabelle gibt die Kompatibilit t mit GNU Emacs derzeit mit etwa 95 % an, wobei die restlichen L cken noch geschlossen werden. Für eval-exec/neomacs ist dabei die Abgrenzung wichtig: Die README beschreibt diesen Punkt als Teil des Projekts, nennt aber keine zusätzlichen Leistungswerte. Wer den Code prüft, sollte genau den README-Einstieg und den Branch main heranziehen und die dort genannten Komponenten getrennt betrachten. Das verhindert, dass eine einzelne Funktion als Aussage über das gesamte Repository gelesen wird. Die veröffentlichten Angaben stammen aus der Projektbeschreibung und sind als solche einzuordnen.

Kompatibilitätsversprechen

Kompatibilitätsversprechen ordnet eval-exec/neomacs in eine konkrete technische Aufgabe ein. Die Anzeige-Engine ist ein zentraler Schwerpunkt. Sie rendert ber wgpu und unterst tzt die Backends Vulkan, Metal, DX12 und GL. Das README behauptet, dass etwa 4.000 Zeilen Rust die ungef hr 50.000 Zeilen von xdisp.c ersetzen. Die Engine unterst tzt das Einbetten umfangreicher Medien in Puffer: 4K-Video ber GStreamer und VA-API, GPU-dekodierte Bilder, einen WPE-WebKit-Browser und ein GPU-gest tztes Terminal, alles ber DMA-BUF mit Zero-Copy. Animationen geh ren ebenfalls zum Funktionsumfang: 8 Cursor-Modi, 21 Scroll-Effekte und 10 Puffer- berg nge, alle aus Elisp konfigurierbar. Für eval-exec/neomacs ist dabei die Abgrenzung wichtig: Die README beschreibt diesen Punkt als Teil des Projekts, nennt aber keine zusätzlichen Leistungswerte. Wer den Code prüft, sollte genau den README-Einstieg und den Branch main heranziehen und die dort genannten Komponenten getrennt betrachten. Das verhindert, dass eine einzelne Funktion als Aussage über das gesamte Repository gelesen wird. Die veröffentlichten Angaben stammen aus der Projektbeschreibung und sind als solche einzuordnen.

Installation und Build

Installation und Build ordnet eval-exec/neomacs in eine konkrete technische Aufgabe ein. Vorgefertigte Pakete werden f r Linux (AppImage, .deb, .rpm, Tarball, f r x86_64 und aarch64), macOS (experimentelles .dmg f r Apple Silicon) und Windows (experimenteller Installer .exe und portables .zip) aufgelistet. Das README enth lt auch Schritte zum Erstellen aus dem Quellcode: Repository klonen, optional mit nix develop in die Entwicklungsumgebung wechseln, dann cargo xtask fresh-build --release ausf hren, um Rust-Code zu kompilieren, Elisp zu bootstrappen und den portablen Dump zu erzeugen. Das resultierende Bin rprogramm wird als ./target/release/neomacs gestartet. Plattformabh ngigkeiten und Test-Suiten werden in docs/building.md referenziert, das im README nicht wiedergegeben wird. Für eval-exec/neomacs ist dabei die Abgrenzung wichtig: Die README beschreibt diesen Punkt als Teil des Projekts, nennt aber keine zusätzlichen Leistungswerte. Wer den Code prüft, sollte genau den README-Einstieg und den Branch main heranziehen und die dort genannten Komponenten getrennt betrachten. Das verhindert, dass eine einzelne Funktion als Aussage über das gesamte Repository gelesen wird. Die veröffentlichten Angaben stammen aus der Projektbeschreibung und sind als solche einzuordnen.

Zwei Threads

Zwei Threads ordnet eval-exec/neomacs in eine konkrete technische Aufgabe ein. Die Architektur bersicht im README sagt, dass alles in Rust ber zwei Threads l uft: Der Emacs-Thread besitzt die Elisp-Laufzeit und den Editor-Zustand, w hrend der Render-Thread die GPU besitzt. Designprinzipien, eine vollst ndige Modul bersicht und die Begr ndung f r Rust und wgpu sollen in docs/ARCHITECTURE.md stehen. Das README betont au erdem, dass das gesamte Frontend, von Rendereffekten bis hin zu in WGSL geschriebenen GPU-Shadern, f r Elisp offen ist, sodass Benutzer die Pixel hacken k nnen und nicht nur den Text. Für eval-exec/neomacs ist dabei die Abgrenzung wichtig: Die README beschreibt diesen Punkt als Teil des Projekts, nennt aber keine zusätzlichen Leistungswerte. Wer den Code prüft, sollte genau den README-Einstieg und den Branch main heranziehen und die dort genannten Komponenten getrennt betrachten. Das verhindert, dass eine einzelne Funktion als Aussage über das gesamte Repository gelesen wird. Die veröffentlichten Angaben stammen aus der Projektbeschreibung und sind als solche einzuordnen.

WIP-Status und Abhängigkeiten

WIP-Status und Abhängigkeiten ordnet eval-exec/neomacs in eine konkrete technische Aufgabe ein. Die Statustabelle schl sselt den Fortschritt nach Bereichen auf. Die GNU-Emacs-Kompatibilit t wird mit etwa 95 % angegeben und die L cken werden weiter geschlossen. JIT-Kompilierung und Inline-Caching funktionieren, werden aber profiliert und verbessert. Der GC ohne Pausen reift heran. Von Elisp aus hackbare GPU-Shader und Oberfl chen sind fr h und werden erweitert. Die Rust-Elisp-Laufzeit, einschlie lich Evaluator, Bytecode-VM und portablem Dump, wird refaktoriert und getestet. Die GPU-Anzeige- und Layout-Engine ist fr h und verbessert sich. Inline-Bilder, 4K-Video und der WebKit-Browser funktionieren heute, bleiben aber experimentell. Das leistungsstarke neo-term (GPU-Terminal) befindet sich in Entwicklung, und Animationen werden poliert. Die Leistung wird profiliert und benchmarkt, echtes Multi-Threading-Elisp befindet sich in Design und Forschung, und der TUI-Renderer ist nutzbar, wird aber noch poliert. Die Cross-Platform-Unterst tzung priorisiert Linux und macOS; Windows wartet auf Tests, WASM, Android und iOS sind geplant. Für eval-exec/neomacs ist dabei die Abgrenzung wichtig: Die README beschreibt diesen Punkt als Teil des Projekts, nennt aber keine zusätzlichen Leistungswerte. Wer den Code prüft, sollte genau den README-Einstieg und den Branch main heranziehen und die dort genannten Komponenten getrennt betrachten. Das verhindert, dass eine einzelne Funktion als Aussage über das gesamte Repository gelesen wird. Die veröffentlichten Angaben stammen aus der Projektbeschreibung und sind als solche einzuordnen.

GPL-3.0

GPL-3.0 ordnet eval-exec/neomacs in eine konkrete technische Aufgabe ein. In den Danksagungen werden wgpu, winit und cosmic-text als Bibliotheken genannt, mit denen das Projekt gebaut wird, und die Cursor-Animationen wurden von Neovide inspiriert. Die Lizenz ist GPL-3.0, dieselbe wie bei Emacs. Der bereitgestellte Lizenzauszug enth lt jedoch keinen tats chlichen Lizenztext; er stellt nur fest, dass keine bliche LICENSE-Datei gefunden wurde. Daher sind die genauen Lizenzbedingungen im bereitgestellten Material nicht verf gbar. Das README beschreibt das Projekt au erdem als langfristig und l dt zu Spenden ber GitHub Sponsors ein. Es macht keine Aussagen zu Sicherheit, Support oder Garantie. Für eval-exec/neomacs ist dabei die Abgrenzung wichtig: Die README beschreibt diesen Punkt als Teil des Projekts, nennt aber keine zusätzlichen Leistungswerte. Wer den Code prüft, sollte genau den README-Einstieg und den Branch main heranziehen und die dort genannten Komponenten getrennt betrachten. Das verhindert, dass eine einzelne Funktion als Aussage über das gesamte Repository gelesen wird. Die veröffentlichten Angaben stammen aus der Projektbeschreibung und sind als solche einzuordnen.

Redaktionelles Fazit

Geeignet ist eval-exec/neomacs für Leser, deren konkreter Bedarf zu den in der README genannten Komponenten passt. Nicht voraussetzen sollte man undokumentierte Leistungswerte oder vollständige Produktionsreife. Vor einer Entscheidung zuerst den dokumentierten Einstieg für neomacs, den Branch main und die passende Lizenz GPL-3.0 im eigenen Szenario prüfen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes