Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

With nvim, there has been quite the resurgence of Vim. Good software tends to be resilient. I believe both emacs and vim will see many, many more years.


Neovim feels indeed the proper future-proof evolution of a standard. Its still a bit cumbersome to setup (fonts, lots of plugins to configure, opinionated and overly decorated UI etc.). The acid test of maturity is the dry functionality you get out of the box in a fresh linux. It should be "just right", introducing the new thinking and functionality of neovim without getting in the way.


I actually like `nvim --clean`, which is just the basics. Early on in the Neovim project, a lot of heirloom defaults were changed to be more modern, resulting in a better (IMHO) out-of-the-box experience. I use `nvim --clean` as my man-page viewer:

  MANPAGER=nvim --clean -c "colo sorbet" +Man!
Startup speed is blistering.

My current config is pretty stable, and not that large. But if it were causing issues, I'd seriously consider only doing LSP setup, which is not that onerous with the latest APIs (it was already fairly easy with `vim.lsp.start`, but `vim.lsp.config` and `vim.lsp.enable` make it easier still: https://neovim.io/doc/user/lsp.html).


I wonder, will there be something to emacs, as nvim is to vim?


Emacs seems to be a local maximum that is difficult to overcome. An entire Lisp Machine environment would be better, but it would be a tremendous undertaking and the specialists, i.e. emacs devs, don't seem to be interested in such a thing.

A multithreaded version of emacs would also be an interesting addition; I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.


> I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.

Everyone including the maintainers would like this to happen. The arguments against it are technical hurdles. Emacs is a large ball of global state and the lisp evaluator hooks into everything, including the display engine, so it's not clear to anyone how to disentangle things to the point where the interpreter lock can be released.


There’s (arguably) an argument to be made that Emacs configuration distributions fit that niche - Doom Emacs, Spacemacs, and Prelude provide varying flavours for different kinds of Emacs users.

Apart from that, I don’t really know what an application would be to Emacs as nvim is to Vim. It’s more like nvim is to Vim what Emacs is to nano, except Emacs came first.


Let's not forget that GNU Emacs also had his competitor, XEmacs which spurred GNU Emacs to improve. Similar with GCC and EGCS where the EGCS later became the new GCC.


This already happened, decades ago. Xemacs was widely deployed for a while. For that matter, vim is the most popular of several editors that did this to vi. (Elvis, stevie, nvi, others probably.) At any rate, I think Xemacs is still more or less maintained, but I haven’t seen anybody use it in decades.


sacrificing all existing elisp code makes a new editor worthless, maintaining compatibility makes it extraordinarily hard to get anywhere.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: