Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron
16 points
23 hours ago
| 12 comments
| github.com
| HN
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.

hypersoar
24 minutes ago
[-]
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.

reply
stevekemp
7 minutes ago
[-]
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.

reply
luckymate
2 hours ago
[-]
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?
reply
imcritic
1 hour ago
[-]
What answer to that question and in this situation would make any sense?
reply
luckymate
30 minutes ago
[-]
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’
reply
embedding-shape
57 minutes ago
[-]
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.

reply
exe34
1 hour ago
[-]
I believe it's called a rhetorical question.
reply
sanskritical
1 hour ago
[-]
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.

reply
kurouna
10 minutes ago
[-]
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!

reply
gozzoo
8 minutes ago
[-]
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.
reply
wiseowise
1 minute ago
[-]
Zed is open source and free (as in beer), to start with.
reply
maybewhenthesun
2 hours ago
[-]
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.

reply
throwa356262
1 hour ago
[-]
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.

reply
chiffaa
7 minutes ago
[-]
> 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/

reply
johanvts
43 minutes ago
[-]
What javascript is in emacs? I often find myself wishing eww had javascript support, a lot of the web is unuseable as it stands.
reply
wiseowise
2 minutes ago
[-]
> Electron

Prepare yourself.

reply
noufalibrahim
1 hour ago
[-]
- 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!

reply
artemonster
1 hour ago
[-]
dry water powder. just add water
reply
subhro
2 hours ago
[-]
Light weight and electron in the same sentence?

Oh well.

reply
chii
2 hours ago
[-]
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.
reply
pjmlp
2 hours ago
[-]
I guess the "eight megabytes and constantly swapping" meme is now lost given Electron.
reply
__d
1 hour ago
[-]
Egacs
reply
dhruv3006
34 minutes ago
[-]
How do you make a electron app light weight ? What are the best practices for windows ?
reply
PacificSpecific
51 minutes ago
[-]
ようこそ

As an aside. What were the CJK IME issues you resolved? Was it related to win32 emacs IME issues?

reply
rasur
1 hour ago
[-]
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".
reply