I don't mean to tear down your project at all. If you want to make an editor, I think that's great. I'm actually working on a text editor of my own. But I think that you've fundamentally misunderstood the appeal of Emacs. It has little to do with the key-bindings, or even any particular part of the user interface. Many people don't even use them. Doom, a very popular Emacs distribution, enables Vim-like bindings by default. It's an old joke that Emacs is a great operating system in need of a good text editor.
The appeal of Emacs is that I can, at any time, with only a few keystrokes, dig in to how it does something and then modify it. The self-documenting and customizable behavior is extremely pervasive. Emacs Lisp is not just there for extensions. Every single layer of the application--save for core primitives--is implemented in it. All of it can be inspected, modified, swapped out, wrapped, hooked into, and basically do anything you want. There's absolutely nothing else like it.
> But I think that you've fundamentally misunderstood the appeal of Emacs. It has little to do with the key-bindings, or even any particular part of the user interface.
You mean the default keybindings for readline and macos? I think you're greatly overestimating the extent to which you can speak for other emacs users. I love the default keybindings and never even thought to change them, and I very much understand being leery of the lisp runtime. The modal editing of vim, doom etc always struck me as pointless typing and too much like issuing commands rather than making typing an extension of your fingers.
This isn't for me (electron—blah; I have microemacs etc), but I 100% get it.
Vim keybindings are not optimized for typing, but for editing.
Yeah! For typing, you could use cat and be done with it. But you think about editing, then ed(1) start to make sense. You think about it a little more and ex(1) makes sense. You want better visual feedback and vi(1) is born. And then you want more programming features and you’ll get vim.
Emacs is what you get when you sidestep the whole process with something as versatile as lisp. Instead of being economical with commands, you just create the specific actions you want
I've found that it's not any better than emacs at this and you end up spending more brainpower and time issuing commands than editing, but of course YMMV. Plus it gives you cred with people who never learned to exit vi, which I suppose counts for something.
Thank you!!! I'm so glad you said that.
"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.
Thank you for the incredibly insightful comment. I completely agree with your definition of Emacs, and I have the utmost respect for its true nature as a fully programmable Lisp environment. You are absolutely right—that infinite extensibility is what makes Emacs unparalleled.
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.
Oh, I don't have much at all, yet. I decided to use a piece tree, which is what VS Code calls the data structure they used. I implemented part of that, then realized that VS Code does it that way partly because of limitations with V8. So now I don't even know if I want to go forward with using it or switch to something simpler.
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 have to agree, if only because when I hear "the emacs keybindings" I wonder, does that mean the defaults that nobody uses, or the ones I've carried around for 20+ years?
As a quick example "M-g" ("Esc" [pause] "g") has been bound to "goto-line" in my emacs startup file for at least 20 years, and is something I press without even really thinking about.
There are many default keys (such as C-x C-f for finding a file), but even core functionality gets rebound to suit my preferences.
I use default keybindings, FWIW. But I agree that my ability to shape Emacs into exactly the tool I want with lisp is the main draw for me.
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.
Just to be clear: you say by ‘dropping’ lisp you’re keeping it lightweight but it’s based on electron? So what does ‘lightweight’ mean in your opinion?
Thank you for the sharp question! You are absolutely right that Electron itself has a baseline memory footprint that isn't small.
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!
How often do you start your editor? I start emacs once at booot and keep it running, using emacsclient to open additional files from the command line.
Look, I think that writing your own editor is useful because one learns a lot. And of course, it doesn't need to use Lisp or even be extendable at all. But it's not Emacs any longer if you remove the Lisp part.
Thank you for the comment!
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!
Is this fucking chatgpt comment?
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!
What answer to that question and in this situation would make any sense?
The motivation/justification from the author why they believe removing lisp but adding Electron somehow sums up to being "lightweight"?
Maybe the author thought of the UX/baggage/legacy or something else when they thought about "lightweight", rather than how much memory/cpu cycles something is using? Not sure, but maybe there is a more charitable reading of it out there.
Probably none. Still I’m curious what is the authors understanding. Whether he actually thinks it is a lightweight solution or whether that’s kind of advertising phrase, like ‘blazingly fast’
I believe it's called a rhetorical question.
None, just another Electron hater.
lisp-free emacs to me is like tomato-free ketchup? I mean, the main reason to use an editor with such arcane keybindings is the way you can live-edit the running editor?
So for me personally there's no demand. But still, if it scratches your personal itch, there are most probably others who would like that itch scratched. It might also because I rarely have to use windows these days and in linux there's not much 'setup' in using normal lispy emacs.
Also, for me , electron based editors have too much input latency.
You might be right! For those who love Emacs for its Lisp environment, this editor is probably not useful at all.
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.
What I need is an emacs with more lisp and less javascript.
If you want a really lean emacs-like editor, there is always mg and microemacs.
Edit: not trying to be a dick or a gatekeeper. This is HN, all ideas should be welcome including the one that dont make sense to some people. And always interesting to see contributions from Japan.
Thank you for the warm welcome!
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!
> What I need is an emacs with more lisp and less javascript
Lem[0] in ncurses mode might be your friend. Unfortunately the BDFL deprecated the SDL frontend seemingly due to the SDL3 breakages, but the web one uses webview + a homegrown system instead of electron and framework magic, so it's still fairly lightweight
its main proposition is that the whole thing is written in Common Lisp, so it retains the hackable model of traditional Emacses without retaining the legacy of GNU Emacs
What javascript is in emacs? I often find myself wishing eww had javascript support, a lot of the web is unuseable as it stands.
If you want an example of an actually lightweight modern desktop editor to take inspiration from, try zed.dev
Zed is written in Rust, insanely fast, consumes virtually no resources, has an Emacs input mode (which I use exclusively) and despite not having the greatest support for Emacs LISP (only via limited third party extension, its singular flaw) has replaced emacs-ng as my daily driver.
Thank you for the comment and the suggestion!
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!
I’ll never get why people hype up Zed. Sublime Text already has all the same perks—and beats Zed at the very things it claims to improve. Sure, it might not have every advanced feature, but for “vibe coders” who don’t need a full IDE and just want to skim or tweak generated code, Sublime Text is the better choice.
Someone already mentioned the hoarderware issue, which is big for me, so I'll give my other concern.
Years ago on Twitter I believe it was lcamtuf that asked "Would you pipe a text file into less?" and Dan Kaminsky (RIP) replied -- "Not now that you asked if I would, no." The obvious implication is that people largely didn't think of simple text parsing utilities as places of concern for security issues, but that is not really in line with reality. I work with crypto and it seriously matters if I got owned in that I can lose amounts of money entrusted to me that I could never hope to recover or repay. I believe it is a basic fiduciary duty to use as much code as possible written in safer languages. Sublime Text is a massive C++ app and I can't look at the code. I am going to preferentially treat the Rust app as better. There's plenty of CVEs in editors. If I could I would replace every binary written in an unsafe language on every machine I ever use.
My editor touches every bit of infrastructure I have. I use it every day to change the behavior of production machines. I have no choice to treat my editor as trusted. So it needs to be trustworthy to the maximum degree possible.
I truly appreciate your perspective. It’s a very sobering reminder of the responsibility that comes with building a tool that handles code and data.
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.
Zed is open source and free (as in beer), to start with.
It’s truly amazing that an editor as powerful as Zed is available for free. We’re living in a great era!
Many, many years ago I was a dedicated Emacs user.
My recollection is that there was a very lightweight binary that would launch a single window utilising an existing Emacs process that (of course) you usually alrwady had running, to show a dedicated window for editing a single file - which is Notepad's raison d'etre. So as a Notepad replacement I can't really see a place in the world for something like this.
I am not in any way competent to comment on CJK issues in Emacs as I can't do any of those languages. I can appreciate the desire to address those.
To answer OP's question, I doubt there is much demand for a knobbled Emacs like this, but on the other hand, I think you should do open source software primarily for yourself because doing it for others' sake will grind you down. But if what really pleases you is to make an impact for a lot of other people, directing your energies into solving CJK issues in Emacs itself would be a lot more impactful (though I am sure a lot more challenging too).
Thank you for the thoughtful comment and advice! The lightweight binary you mentioned is likely emacsclient, which is indeed a good way to use a running Emacs process as a quick editor.
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!
I guess the "eight megabytes and constantly swapping" meme is now lost given Electron.
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.
Egacs
Light weight and electron in the same sentence?
Oh well.
Light weight has become a marketing term that targets software developers who have gotten sick of bloat and want their software to run fast and take less resources. It used to mean a trade-off between feature rich and speed. It's been so over-used now that i automatically ignore it unless there's demonstrated reason(s) for it being called light weight.
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.
- Lisp Free x Emacs like
- Lightweight x Electron
Contradictions. Writing ones own editor is a bit of a rite of passage though. So, on that front, Congratulations!
I understand the irony! It certainly sounds like a contradiction.
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!
dry water powder. just add water
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
"Lisp free", "Emacs-like".
Pick one. You can't claim to have both of those in the same editor.
To be fair the original EMACS did not have Lisp scripting, neither do implementations like MicroEmacs. Are those not Emacs-like?
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.
How do you make a electron app light weight ? What are the best practices for windows ?
That is a very fair question. When I say "lightweight," I am focusing on perceived speed and responsiveness rather than memory footprint.
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.
ようこそ
As an aside. What were the CJK IME issues you resolved? Was it related to win32 emacs IME issues?
Thank you for the welcome! Yes, it is exactly related to the Windows Emacs IME issues. Emacs is a product I deeply respect, but configuring it to handle Japanese input smoothly on Windows has always been a challenge for me.
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!
I understand now and thank you for explaining the issues to me.
Good luck on your project!
Thank you!
With respect, you should learn Lisp - it will allow you to turn Emacs into whatever you want. In my opinion just keeping the Emacs keybindings but dropping all the other advantages of Emacs is missing the point entirely, and using Electron instead is just - as the saying goes - "adding insult to injury".
Thank you for your candid feedback. I completely agree with your point—the true power of Emacs lies in its Lisp environment and infinite customizability.
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.
I do (also sometimes) use Emacs on Windows, but I must admit I have little experience of the issues surrounding Japanese textual input (I've not checked but I would have automaticaly assumed "there's an Emacs mode for that", but perhaps not) - without that additional requirement just a plain old basic Emacs would have worked out of the box, no?
But anyway, good luck in your travels in scratching that itch! :)
I was going to ask. I'm not big on Emacs, but ripping out Lisp isn't that removing the part that makes Emacs Emacs? Like, they removed the important part.
Pretty much yes. Emacs is basically a Lisp execution environment with a customisable text-editor included.
why electron? why is it closed source?
Those are great questions.
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!
> Electron
Prepare yourself.
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!