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.
> 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.
Many, many years ago I was a dedicated Emacs user.
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).
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?
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!
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.
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’
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.
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.
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.
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.
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.
> 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
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.
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".
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.
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.
> 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 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.
Many, many years ago I was a dedicated Emacs user.
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).
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?
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?
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.
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’
None, just another Electron hater.
I believe it's called a rhetorical question.
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.
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.
Zed is open source and free (as in beer), to start with.
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.
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.
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.
> 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.
I guess the "eight megabytes and constantly swapping" meme is now lost given Electron.
Egacs
why electron? why is it closed source?
Light weight and electron in the same sentence?
Oh well.
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.
- 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!
dry water powder. just add water
How do you make a electron app light weight ? What are the best practices for windows ?
ようこそ
As an aside. What were the CJK IME issues you resolved? Was it related to win32 emacs IME issues?
> Electron
Prepare yourself.
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".
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.