Hi HN. I am a programmer from Japan who loves Emacs. I am building elecxzy. It is a free (zero-cost), lightweight, Emacs-like text editor for Windows.
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.
> 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.
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.
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
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.
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.