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.

> 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.

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.

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!

What answer to that question and in this situation would make any sense?

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!

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.

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.

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

[0] https://lem-project.github.io/

What javascript is in emacs? I often find myself wishing eww had javascript support, a lot of the web is unuseable as it stands.

Egacs

dry water powder. just add water

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.

To be fair the original EMACS did not have Lisp scripting, neither do implementations like MicroEmacs. Are those not Emacs-like?

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!

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 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.