Hacker News Reader

Comment by _peeley | Hacker News Reader

I see a lot of parallels between Emacs' problems now and Vim's problems a few years ago: opaque maintenance/contributions, poor performance inherited from core design decisions made decades ago, the burden of backwards compatibility for legacy systems, etc. I think Emacs users and the community would benefit from a ground-up modern rewrite much like Neovim did for Vim, especially compared to this project which adds even more layers to maintain. It certainly addresses performance issues, but Emacs seems to have enough problems with things breaking spontaneously - I don't think adding a JavaScript runtime to the mix will do any bit of good there.

View on HN

The last time I had things randomly break under me due to elisp was a long long time ago. Such that, I really can't remember it.

And as a user of emacs, the stability has been quite nice. The speed has mostly only hurt around things I'd expect to hurt. (Long long long lines, for example.)

I can see the allure of language servers. But, to me they are basically a modern cscope. With json being the transport. Not bad, but hardly magical or unforseen. (Granted, getting the pockets of microsoft has been nice.)

What sort of spontaneous breaks are you referencing?

I tend to agree with this - Emacs is my daily driver and the way I use it, it's really 1) a tightly integrated window manager/text editor powered by elisp, and 2) a great community providing additional functionality. It would be relatively easy to make something to replace (1) for me, but (2) is tough. I'd love to know how far we could get with an updated editor and rendering system, with backward compatibility for emacs code via some sort of emacs/new-system translation layer - I was really excited for xi-editor for that reason because it seemed like it might be a good platform for those kinds of experiments.

This sounds like a description of Emacs most of a decade ago, not long after I started using it, rather than of Emacs today.

Port of Emacs to rust https://github.com/remacs/remacs

Emacs-ng is actually a fork of remacs. Many of the same people are involved.

Neovim is not a rewrite.

No, but it tackles the same aforementioned issues:

> opaque maintenance/contributions, poor performance inherited from core design decisions made decades ago, the burden of backwards compatibility for legacy systems, etc.

The main goal of NeoVim is to ditch the backwards compatibility and simplify the codebase. Sure, it isn't a from-scratch rewrite, but it's a very deep fork.

The magic of it is it just keeps on working. All those big changes didn't cause any instability for even once.

>Sure, it isn't a from-scratch rewrite, but it's a very deep fork.

Not really. I contribute to Neovim and in my experience the architecture is the same as in Vim. The features that were added in Neovim first do have a different architecture and are better designed though. However these new features only make a tiny fraction of all of Vim's features.

The upcoming 0.5 release will feel like a rewrite to some folks though, the entire config system is Lua-first right down to support of an init.lua instead of init.vim in vimscript. I've been converting my setup over to Lua and it's so much more understandable and sane vs. some bespoke scripting language that made more sense in 1990.

(it should also be mentioned the old vimscript support isn't going away, you can still use old configs)

Reply on news.ycombinator.com