Hacker News Reader

Comment by sph | Hacker News Reader

Making a fast editor is such a common hobby, everybody seems to be working on one these days apparently, yet memory safety and speed has never been a real problem in editors.

It would be much more impressive to explore a novel approach for editors more extensible than Emacs, or with a more innovative editing model than vim's.

If we are reinventing the wheel, why not at least try to make a better wheel that's never been done before?

View on HN

Editors don't get made in Rust because people want better memory safety in an editor. They're made in Rust because people like Rust, and the Rust trademark makes anything associated more cool, no other language has reached such a godlike marketing status.

Counterpoint: The only really pleasant + mainstream + cross-platform languages for new client/desktop software today are Go and Rust. Depending on the Python interpreter or the JRE or whatever is a huge pain when you don't control the environment. Just spitting out a native binary really helps. (I say this as someone who doesn't personally find Go pleasant, but I understand that lots of other people do, and I respect the tradeoffs it made.)

It's called a hype cycle. A decade ago it was editors written in Go.

Did some such editor succeed?

Yet there are common complaints about how slow emacs is, same for VSCode performance.

And a better wheel is much harder (but there is a feature request for helix mode, that's more innovative than vim, maybe they'll add that)

> with a more innovative editing model than vim's

I think Helix tries to do that

Kakoune too. But if a project focuses on a novel editing model and not some other aspect of an editor, then implementing it inside Emacs might be the best approach.

If implemented inside Emacs, then it composes with the rest of its package ecosystem. Kakoune, Helix, etc. are somewhat set back by having to reproduce functionality equivalent to Magit, Org, LSP mode, and so on in order to be on equal footing for many users.

Evil, Meow, and God mode seem to show that Emacs is a good platform for such experimentation.

I don't have a lot of experience with Emacs, let alone evil (and none at all with meow or god). But my experience with it was that evil felt distinctly.. hacky? For example, Evil felt like it interfered with selecting restarts in Sly.

I've had similar issues with VscodeVim being weird in VSC. Ultimately the text editor is so core to a text editor (duh) that deeply modifying it is bound to give a worse experience than implementing it from scratch, even if it does give you a lot of nice stuff 'for free'.

> But my experience with it was that evil felt distinctly.. hacky?

Honestly that was my experience with all of Emacs, not just evil. I tried Doom Emacs a while ago, and while Doom does a great job at abstracting a lot of that hackiness away, whenever I tried to configure something myself it just felt like the entire Emacs ecosystem is based on random hacked-together 10000 line elisp scripts with 3 GitHub stars which abuse some weird undocumented legacy parts of Emacs. Basically everything except a few famous big packages (eg. Org, Magit, etc.) felt very weird to use.

Kinda surprising considering how comprehensive the Neovim ecosystem feels compared to Emacs', despite it also being a very niche editor

Reply on news.ycombinator.com