kurouna

Thanks for the comment! I completely agree with the idea of decoupling the GUI from the Lisp/terminal. I think it's about time for a refresh!

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!

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!

Thank you everyone for the insightful comments and feedback!

I've learned a lot from this discussion, especially regarding software architecture and the philosophy of Emacs. I’ll reflect these insights in the development of elecxzy.

Looking forward to sharing more updates with you in the future!

kurouna

I just ran some simple measurements on my machine to see how it compares. These are just informal benchmarks, but I thought the results might be interesting:

Environment:

Windows 11 Pro 25H2

Intel Core i5-8400 @ 2.8GHz, 16GB RAM

VS Code 1.109.5

elecxzy 0.0.19 (Current dev version)

Memory Usage (Idle):

elecxzy: ~120–125 MB

VS Code: ~430–450 MB (with only the Japanese language pack enabled)

With a 50MB Markdown file open:

elecxzy: ~235 MB

VS Code: ~590 MB

(Note: The 50MB file was programmatically generated for this test.)

While it certainly can't compete with the memory footprint of Notepad or Zed, I've tried to keep it reasonably lightweight for an Electron-based environment by being selective about the features I include.

You’re right that "lightweight" is a loaded term. For this project, I don't mean a small memory footprint—after all, it's Electron.

What I’m aiming for is "lightweight" in terms of perceived performance and simplicity. I wanted to match the near-instant startup and the snappy typing feel of a basic text editor (like Notepad), while still having the Emacs keybindings I love.

By stripping away the heavy IDE-like features and focusing on core editor responsiveness, I'm trying to make it feel "light" for daily, quick tasks.

I understand that for many, Lisp is the soul of Emacs.

When I use the term "Emacs-like," I’m specifically referring to the UI, UX, and the muscle memory of its keybindings, rather than trying to build a full Lisp-based clone or a replacement for the original.

My goal is simply to package that unique physical typing experience into a standalone, zero-setup application for a niche group of users (including myself) who value that specific workflow.

It’s truly amazing that an editor as powerful as Zed is available for free. We’re living in a great era!

I’m writing these comments in Japanese and using AI to translate them into English, as I’m not a native speaker. I want to make sure I can communicate my thoughts and technical details as accurately as possible to this community.

I apologize if the phrasing feels a bit "AI-like" sometimes, but the ideas and the project itself are 100% mine!

I agree that extensibility is one of the core charms of Emacs!

That said, when it comes to keybindings, I’ve actually stuck with about 95% of the defaults. The only exception I can’t live without is exactly what you mentioned:

(global-set-key "\M-g" 'goto-line)

I've used that for so long that my fingers just do it automatically. It’s funny how even a "minimal" user like me has that one specific rule that feels essential.

I actually went through the same VS Code articles and ended up implementing a minimal Piece Table for this project. I focused on adding just enough functionality to handle Undo/Redo according to my specific needs.

So far, it has been working well for my use case. Since the codebase is compact, it is straightforward to test and maintain. For a solo project, I've found that using a data structure I can fully grasp is an advantage.

I’m interested to see where your project goes, whether you stick with Piece Tree or pivot. Building an editor from scratch is a unique experience, isn't it?

I’m ready!!!

I know Electron has a reputation, but surprisingly, its startup speed isn't that different from the native Notepad. It does eat a fair amount of memory, of course—but I've tried to make it so snappy that you might forget it's Chromium-based until you check the Task Manager!