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.
luckymate•2h ago
imcritic•2h ago
exe34•1h ago
embedding-shape•1h ago
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.
luckymate•59m ago
wiseowise•27m ago
kurouna•24m ago
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!