Ask HN: Let's rethink the architecture and future of Emacs
1•kurouna•2h ago
Comments
kurouna•1h ago
First and foremost, I love Emacs and have the utmost respect for its Lisp-based ecosystem. It is undoubtedly one of the most successful and enduring examples of user-extensible software in history.
Recently, I’ve been reflecting on the nature of Emacs: What truly defines it? Is it the Lisp engine, the buffer-centric workflow, or the core philosophy of ultimate hackability? I realize this has been debated many times over the decades, but it feels worth revisiting in the context of the technologies available to us in 2026. A complete rewrite isn't the only answer; out of pure intellectual curiosity, I’d simply like to step back and reconsider its future from where we stand today.
Historically, Emacs began as a set of macros on TECO, not a Lisp-based system. Lisp eventually became its greatest strength, but I wonder if it has also become a constraint. Is it best for Emacs to continue evolving along its current path, or is it time for a more radical shift? What kind of future would be truly exciting for the next generation of hackers?
If we were to design Emacs from scratch today, would we still build it around its current C core and Lisp engine? Or could a different stack preserve its spirit while unlocking new possibilities? For
example:
* A core implemented in a modern systems language like Rust for performance and safety.
* A decoupled UI layer leveraging modern rendering engines or web technologies to natively handle complex layouts and CJK environments without legacy constraints.
* Lisp (or a similar high-level language) retained purely for user-level customization, rather than driving the underlying UI architecture.
Another question is its direction: should Emacs continue evolving into an all-in-one IDE, or should it return to being the "ultimate text editor," delegating heavy IDE responsibilities to LSP-based tools?
What specifications or technologies would make a "Modern Emacs" truly exciting for you? Are there technical or cultural reasons preventing the adoption of a modern stack, assuming the core philosophy remains intact?
Please note: This is not a critique of Lisp or the current Emacs. Whether it's a continuation of its current evolution or a completely new architecture, my only interest is to hear how we all envision its future. This is purely a thought experiment, and I hope you enjoy the discussion!
kurouna•1h ago
Recently, I’ve been reflecting on the nature of Emacs: What truly defines it? Is it the Lisp engine, the buffer-centric workflow, or the core philosophy of ultimate hackability? I realize this has been debated many times over the decades, but it feels worth revisiting in the context of the technologies available to us in 2026. A complete rewrite isn't the only answer; out of pure intellectual curiosity, I’d simply like to step back and reconsider its future from where we stand today.
Historically, Emacs began as a set of macros on TECO, not a Lisp-based system. Lisp eventually became its greatest strength, but I wonder if it has also become a constraint. Is it best for Emacs to continue evolving along its current path, or is it time for a more radical shift? What kind of future would be truly exciting for the next generation of hackers?
If we were to design Emacs from scratch today, would we still build it around its current C core and Lisp engine? Or could a different stack preserve its spirit while unlocking new possibilities? For
example:
* A core implemented in a modern systems language like Rust for performance and safety.
* A decoupled UI layer leveraging modern rendering engines or web technologies to natively handle complex layouts and CJK environments without legacy constraints.
* Lisp (or a similar high-level language) retained purely for user-level customization, rather than driving the underlying UI architecture.
Another question is its direction: should Emacs continue evolving into an all-in-one IDE, or should it return to being the "ultimate text editor," delegating heavy IDE responsibilities to LSP-based tools?
What specifications or technologies would make a "Modern Emacs" truly exciting for you? Are there technical or cultural reasons preventing the adoption of a modern stack, assuming the core philosophy remains intact?
Please note: This is not a critique of Lisp or the current Emacs. Whether it's a continuation of its current evolution or a completely new architecture, my only interest is to hear how we all envision its future. This is purely a thought experiment, and I hope you enjoy the discussion!