Comment by spartanatreyu

> - if a main point is modal editing, vim lets you use your muscle memory everywhere, since vim mode is pretty common (plus extensions like vimium, and almost certainly having vim on any machine you ssh to).

There's not a lot of devs who want to directly use the basic vim experience (without any plugins/config). Even with similar keybinds, most devs aren't going to want to switch between editors. Instead, most devs are going to want to use an editor with a personalised setup and set of capabilities. The exception are those few devs who are actually sshing between many machines with a raw-dogged editor experience because it's a hard requirement, in which case they can continue to use nano, vim, vi, emacs, ed, etc...

> - helix seems to be both opinionated about simplicity (no terminal integration) and not very extensible with plugins (no linting unless it comes from the lsp)? That seems to be a limited combination, forcing you to have your whole setup built upside the editor (tmux etc).

Helix was actually built with the intention of having a whole setup built inside the editor, but that's not what the community wanted. So helix has been transitioning into adding a plugin system so the community can turn it into an all-in-one editor. The plugin system is not enabled in the main releases yet, but it's been in it's own branch for a while with a community of plugins already developed and with devs using them now. But all things considered it is the right move to hold back the release and get the shape of the plugin system as good as possible, because if it were released then needed to be changed, you'd be negatively affecting all the plugins that were released before the change.

---

The biggest upside is fixing the poor UX decision that's been baked into vi and carried into vim and neovim. That being, the order of operations which make it harder to see your changes before you commit them, making unintended side-effects easier to occur.