[hypersoar]

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.

[throwaway27448]

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

[xigoi]

Vim keybindings are not optimized for typing, but for editing.

[skydhash]

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

[throwaway27448]

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.

[kurouna]

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.

[kurouna]

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.

[hypersoar]

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.

[kurouna]

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?

[stevekemp]

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.

[rpdillon]

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.

[kurouna]

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.