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!
16 karma · joined February 18, 2026
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!
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!
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
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.
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.
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.
I apologize if the phrasing feels a bit "AI-like" sometimes, but the ideas and the project itself are 100% mine!
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.
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 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!
To be honest, this project is currently in a phase of personal hobby, self-improvement, and self-satisfaction. I must admit that it is not yet ready for mission-critical work.
While I certainly haven't included any malicious code, there are real risks: the app could crash and lose data, or underlying libraries might have vulnerabilities that I haven't had the capacity to fully audit yet. As I’m still experimenting with the architecture alone, I’m not ready to open the source code just yet.
However, your feedback makes me realize how important the "trustworthiness" is for a professional tool. If there is a clear demand for this kind of software and many requests for it to be open-sourced, I would definitely love to consider it as the project matures.
Thank you for sharing such a serious and important viewpoint.
"Making typing an extension of your fingers" is exactly what I was aiming for. I personally love the default Emacs keybindings and the "muscle memory" they provide, so I wanted to create a tool that focuses purely on that physical experience.
Why Electron? To be honest, I was simply interested in exploring the technology. But as I started building, I realized that Electron (and web technologies in general) allowed me to solve complex UI/UX issues, like the Japanese IME cursor tracking on Windows, much more easily than other frameworks.
Why closed source? Currently, I am prioritizing building the features I personally want. The internal architecture is still in a state of trial and error, and the code is changing rapidly. I want to focus on refining the tool first. Once I feel more confident in the stability and quality of the codebase, I may consider making it open source in the future!
As I've discussed in other threads, my goal was to extract the physical UX and muscle memory of Emacs and bring it into a modern, zero-config environment. It might be a "dry water" approach, but it's what works best for my daily workflow.
Regardless of the contradictions, the experience of building my own editor has been truly exciting. Thank you for the comment and the encouragement!
Here is how I approached it in elecxzy:
Core Implementation: I implemented the core editor logic, including a custom Piece Table and Virtual Rendering, from scratch. By keeping everything outside of Electron itself as minimal and simple as possible, the editor remains very snappy.
No Extensions or Lisp: Since it doesn't have a Lisp environment or an extension system, the startup process is very straightforward. While it might not be as instant as the native Notepad, it is as fast as a simple, optimized Electron app can be.
I made a quick video comparing its startup speed with Notepad. The post is in Japanese, but you can see how quickly it launches in the video: https://x.com/elecxzy/status/2022003439757336583
For me, the goal was to ensure that the input latency and the feeling of opening the app don't hinder the "flow" of taking quick notes.
To answer your question: I actually start my editor many times a day. I know the "start once and use emacsclient" workflow is the standard and most efficient way for Emacs users, but I personally tend to open and close editor windows frequently, just like using a simple notepad.
Regarding the Lisp part, I completely agree with you. As I mentioned in other threads, if you remove Lisp, it is absolutely not Emacs anymore.
I am not trying to build a true Emacs, nor am I trying to deny its great philosophy. I just deeply love the physical typing experience and muscle memory of Emacs keybindings. My goal was simply to extract that specific UX and package it into a standalone app that I could run immediately without any setup.
So you are right—it is just a personal project to recreate the typing feel I love, rather than an Emacs replacement!
You are right that if elecxzy were just for editing a single file, it might not offer much over a standard Notepad. However, the real value I wanted to achieve is the ability to view, edit, and integrate multiple sources using muscle memory, without touching the mouse.
While it runs as a simple standalone window, it supports Emacs window splitting commands like C-x 2, C-x 3, and C-x 1.
Here is a quick video I posted a while ago (the text is in Japanese, but you can see the window splitting in action): https://x.com/elecxzy/status/2020370174818631769
As for contributing to the upstream Emacs to fix CJK issues, I agree that it would be a more impactful approach for the community. But I really appreciate your advice about doing software for myself. I will continue to work on this project for my own use and enjoyment. Thank you for the great advice!
If my goal was to build a true successor or alternative to Emacs, dropping Lisp and using Electron would indeed be a completely wrong approach.
However, my goal was much simpler and narrower. I wanted a zero-setup, standalone notepad that natively supports Emacs' complex prefix keybindings (like C-x 2 to split windows or C-x b to switch buffers) right out of the box. While simple keys like C-n or C-f can be easily configured in most modern editors, perfectly replicating the sequence and feel of prefix keys usually requires installing plugins and writing complex configurations.
Additionally, as I mentioned in another thread, using web technologies allowed me to solve the Japanese IME cursor tracking issues on Windows natively.
So you are absolutely right: this project misses the core philosophy of what makes Emacs great. But for my specific daily need—a lightweight notepad with built-in Emacs muscle memory—it perfectly scratches my own itch.
When I call my project "Emacs-like," I certainly don't mean to deny or replace that beautiful philosophy. I am simply a software engineer who deeply loves the UI, UX, and keybindings that Emacs pioneered.
My goal was just to recreate that specific physical experience as a standalone application. I truly love the sensation of operating an editor entirely by muscle memory and pure reflex—allowing the words in my head to flow seamlessly onto the screen without consciously thinking about the tool itself. I just wanted to package that exact typing experience into a zero-setup app.
By the way, I am very curious about the project you mentioned! What kind of text editor are you working on? I would love to hear about it.
There were two main pain points I desperately wanted to solve for my daily workflow:
1. Prefix keys being swallowed by the IME: In Windows Emacs, if your IME is ON and you try to split the window using C-x 2, the 2 (or full-width ２) gets captured by the IME. The command fails, meaning you constantly have to toggle the IME OFF just to run basic window or buffer commands. In elecxzy, I implemented fine-grained control: when the editor enters a "prefix state" (like after pressing C-x or C-c), it actively prevents the IME from capturing the next keystroke. This allows you to smoothly execute commands like C-x 2 or C-x b even while the IME is left ON.
2. IME User Experience (Positioning and Fonts): In Windows Emacs, unless you apply specific patches or complex configurations, the IME candidate window often fails to appear right next to the text you are typing. Furthermore, the font used during IME composition often differs from the editor's main font. These details really hurt the overall typing UX. By using Electron, elecxzy places an invisible <textarea> exactly at the virtual cursor's pixel position. This lets the browser engine handle the IME natively. The candidate window always tracks the cursor perfectly and the composition text seamlessly matches the editor's styling, without requiring any special configuration from the user—it works smoothly just by running elecxzy.exe.
Eliminating these small, daily frictions was my biggest motivation for building this!
To answer the "Why Electron and JS?" question from the thread: honestly, it didn't start as a strict technical decision. It started purely out of my curiosity as a software engineer.
I use VS Code at work, and I just wanted to see what its underlying technology (Electron) was like to build with. Once I started playing with it, I realized it was a remarkably solid and flexible platform. That inspired me to try building something I had always wanted: a zero-setup, lightweight Emacs-like editor.
As a happy side-effect, using web technologies allowed me to use the Japanese IME without any stress, just like Windows Notepad. Unlike Windows Emacs, which sometimes requires special configurations, I was able to make it work just by running elecxzy.exe.
So while it lacks the beautiful Lisp ecosystem of true Emacs (like Lem), it started as a fun technical exploration that eventually became my daily driver!
I just made this for people like me, who instinctively press C-f instead of the right arrow key, but just want to start typing immediately without any setup.
As for the input latency, it might indeed be slower than native editors like Notepad. However, by using a custom Piece Table and virtual rendering, I personally don't feel the delay on a modern PC, and I am very satisfied with the responsiveness for my daily use.
To give a clearer picture of what I mean by "lightweight," here is a quick startup comparison video I took a while ago: https://x.com/elecxzy/status/2022003439757336583
(Sorry for the Japanese text in the video!)
Left: VS Code
Middle: Windows Notepad
Right: elecxzy
As you can see, elecxzy boots up almost as instantly as native Notepad.
To ensure the actual text editing remains just as snappy and responsive as Notepad despite running in a browser engine, elecxzy features several optimizations, including a custom Piece Table and a fully virtualized DOM/renderer.
So in this context, "lightweight" means "Notepad-level startup speed and typing latency, but with native CJK IME support and Emacs keybindings." I should have been clearer about this distinction in my wording!
I have actually tried Zed, and I completely agree with you—it is an outstanding product. Its speed and incredibly low memory footprint are truly impressive.
However, while it does feature an Emacs input mode, I found that the range of supported Emacs commands is still somewhat limited. Because of this restriction, I couldn't quite operate it with the same feel and depth as a dedicated Emacs environment.
That being said, Zed is definitely a masterpiece of modern desktop editors, and its architecture is highly inspiring!