Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron (github.com)
I designed it to be comfortable and ready to use immediately, without a custom init.el. Here is a quick overview:
- Provides mouse-free operation and classic Emacs keybindings for essential tasks (file I/O, search, split windows, syntax highlighting).
- Drops the Lisp execution engine entirely. This keeps startup and operation lightweight.
- Solves CJK (Chinese, Japanese, Korean) IME control issues natively on Windows.
I never managed to learn Lisp. I just copy-pasted snippets to maintain my init.el. However, I loved the Emacs keybindings. I loved operating an editor entirely without a mouse. I wanted an editor I could just open and use immediately. Also, standard Emacs binaries for Windows often have subtle usability issues for CJK users.
So, I thought about whether I could build an Emacs-like text editor using Electron, the same framework as VS Code.
Building an editor inside a browser engine required thinking a lot about what NOT to build. To make it feel native, I had to navigate DOM limitations. I learned that intentionally dropping complex features improves rendering speed. For example, I skipped implementing "word wrap." For syntax highlighting, I did not use a full AST parser. Instead, I used strict "line-by-line" parsing. The highlight colors for multi-line comments are occasionally incorrect, but it is practically unproblematic and keeps the editor fast.
Under the hood, to bypass browser limitations and handle large files smoothly, I implemented a virtual rendering (virtual scrolling) system. For text management and Undo/Redo, I use a custom Piece Table. I built a custom KeyResolver for Emacs chords. I also used koffi to call Win32 APIs directly for precise IME control.
I respect Windows Notepad as one of the most widely used text editors. However, in my daily work or coding tasks, I often felt it lacked certain features. On the other hand, I found VS Code too heavy just to write a quick memo. Even with extensions, it never quite gave me that native Emacs flow. I do not want to replace Notepad, VS Code, or Emacs. If users want rich extensions and heavy customization, I believe they should use Emacs or VS Code. My goal is to fill the gap between them—to build a "greatest common denominator" editor for people who just want an Emacs-like environment on Windows without the setup.
It is still in alpha (so it might not work perfectly), but you can test it on Windows by downloading the zip from the GitHub releases, extracting it, and running elecxzy.exe. For screenshots, basic usage, and keybindings, please check the README on the GitHub project page.
I am looking for feedback: Is there a demand for a zero-config, Lisp-free, "Notepad-like" Emacs-style editor? What are the minimum standard features required to make it useful? I would love to hear your technical insights.
30 comments
[ 3.0 ms ] story [ 58.0 ms ] threadSo 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.
Oh well.
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.
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.
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!
- Lightweight x Electron
Contradictions. Writing ones own editor is a bit of a rite of passage though. So, on that front, Congratulations!
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!
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.
But anyway, good luck in your travels in scratching that itch! :)
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.
As an aside. What were the CJK IME issues you resolved? Was it related to win32 emacs IME issues?
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!
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.
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.
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.
Prepare yourself.
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!
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!
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).
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!
Pick one. You can't claim to have both of those in the same editor.
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