Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

github.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#61

Post by hypersoar »

kurouna wrote: post #45
hypersoar wrote: post #22

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 d…

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…

Oh, I don't have much at all, yet. I decided to use a piece tree, which is what VS Code calls the data structure they used. I implemented part of that, then realized that VS Code does it that way partly because of limitations with V8. So now I don't even know if I want to go forward with using it or switch to something simpler.

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#62

Post by kurouna »

hypersoar wrote: post #61
kurouna wrote: post #45

Earlier quoted context omitted.

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…

Oh, I don't have much at all, yet. I decided to use a piece tree, which is what VS Code calls the data structure they used. I implemented part of that, then realized that VS Code does it that way partly because of limitations with V8. So now I don't even know if I want to go forward with using it or switch to something simpler.

I actually went through the same VS Code articles and ended up implementing a minimal Piece Table for this project. I focused on adding just enough functionality to handle Undo/Redo according to my specific needs.

So far, it has been working well for my use case. Since the codebase is compact, it is straightforward to test and maintain. For a solo project, I've found that using a data structure I can fully grasp is an advantage.

I’m interested to see where your project goes, whether you stick with Piece Tree or pivot. Building an editor from scratch is a unique experience, isn't it?

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#63

Post by kurouna »

rpdillon wrote: post #37
stevekemp wrote: post #25

Earlier quoted context omitted.

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)…

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.

I agree that extensibility is one of the core charms of Emacs!

That said, when it comes to keybindings, I’ve actually stuck with about 95% of the defaults. The only exception I can’t live without is exactly what you mentioned:

(global-set-key "\M-g" 'goto-line)

I've used that for so long that my fingers just do it automatically. It’s funny how even a "minimal" user like me has that one specific rule that feels essential.

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#64

Post by kurouna »

artemonster wrote: post #59
kurouna wrote: post #30

Earlier quoted context omitted.

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…

Is this fucking chatgpt comment?

I’m writing these comments in Japanese and using AI to translate them into English, as I’m not a native speaker. I want to make sure I can communicate my thoughts and technical details as accurately as possible to this community.

I apologize if the phrasing feels a bit "AI-like" sometimes, but the ideas and the project itself are 100% mine!

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#65

Post by kurouna »

wiseowise wrote: post #28
gozzoo wrote: post #24

Earlier quoted context omitted.

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.

It’s truly amazing that an editor as powerful as Zed is available for free. We’re living in a great era!

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#66

Post by kurouna »

alpaca128 wrote: post #41
lelanthran wrote: post #38

"Lisp free", "Emacs-like". Pick one. You can't claim to have both of those in the same editor.

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

I understand that for many, Lisp is the soul of Emacs.

When I use the term "Emacs-like," I’m specifically referring to the UI, UX, and the muscle memory of its keybindings, rather than trying to build a full Lisp-based clone or a replacement for the original.

My goal is simply to package that unique physical typing experience into a standalone, zero-setup application for a niche group of users (including myself) who value that specific workflow.

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#67

Post by kurouna »

chii wrote: post #8
subhro wrote: post #6

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.

You’re right that "lightweight" is a loaded term. For this project, I don't mean a small memory footprint—after all, it's Electron.

What I’m aiming for is "lightweight" in terms of perceived performance and simplicity. I wanted to match the near-instant startup and the snappy typing feel of a basic text editor (like Notepad), while still having the Emacs keybindings I love.

By stripping away the heavy IDE-like features and focusing on core editor responsiveness, I'm trying to make it feel "light" for daily, quick tasks.

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#68

Post by kurouna »

pjmlp wrote: post #7

I guess the "eight megabytes and constantly swapping" meme is now lost given Electron.

I just ran some simple measurements on my machine to see how it compares. These are just informal benchmarks, but I thought the results might be interesting:

Environment:

Windows 11 Pro 25H2

Intel Core i5-8400 @ 2.8GHz, 16GB RAM

VS Code 1.109.5

elecxzy 0.0.19 (Current dev version)

Memory Usage (Idle):

elecxzy: ~120–125 MB

VS Code: ~430–450 MB (with only the Japanese language pack enabled)

With a 50MB Markdown file open:

elecxzy: ~235 MB

VS Code: ~590 MB

(Note: The 50MB file was programmatically generated for this test.)

While it certainly can't compete with the memory footprint of Notepad or Zed, I've tried to keep it reasonably lightweight for an Electron-based environment by being selective about the features I include.

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#69

Post by kurouna »

Thank you everyone for the insightful comments and feedback!

I've learned a lot from this discussion, especially regarding software architecture and the philosophy of Emacs. I’ll reflect these insights in the development of elecxzy.

Looking forward to sharing more updates with you in the future!

kurouna

Re: Show HN: Elecxzy – A lightweight, Lisp-free Emacs-like editor in Electron

#70

Post by rasur »

kurouna wrote: post #47
rasur wrote: post #14

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

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' co…

I do (also sometimes) use Emacs on Windows, but I must admit I have little experience of the issues surrounding Japanese textual input (I've not checked but I would have automaticaly assumed "there's an Emacs mode for that", but perhaps not) - without that additional requirement just a plain old basic Emacs would have worked out of the box, no?

But anyway, good luck in your travels in scratching that itch! :)

Post reply on HN