Comment by kace91

What's the con of the LSP? I'm not familiar with the concept, it sounds like LSP is running in a separate process (which honestly sounds good to sandbox plugins, though I could see it being problematic, I wouldn't be surprised if in practice it functions better to most "integrated" language plugins in other editors.)

As far as tmux I'm a heavy emacs user but honestly I use it mostly as a text editor, I use a separate terminal emulator almost always. So lacking tmux... not something I would notice.

Relearning my Emacs muscle memory is the most daunting thing, but I could probably be convinced for a fast editor written in rust with good defaults.

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