Migrated from #neovim back to #vim after several years of use because:

1. I neither need nor use LSP.
2. I don’t need two scripting languages in a text editor.
3. Neovim #plugin ecosystem is a dependency hell.
4. Neovim #plugins are fancy but that results in also a fancy configuration to maintain.
5. I don’t mind a slow release cycle. My vim workflow hasn’t changed for ages.
6. When logging into remote machines, an off-the-shelf vim installation is almost guaranteed.
7. Even if neovim is installed to a remote machine, it usually fails to load my configuration, given the rapidly changing upstream and plugins requiring always the bleeding edge.
8. I learned #vimscript in 1998 before I had even heard about #lua, and it is more comfortable programming environment for me :-) Before 1998 I was using #qedit in MS-DOS.
9. For local IPC with neovim, a Python package neovim-remote is required. Vim has full local IPC workflow builtin.

@jarkko I wish I could do the same. Only reason I switched to nvim was the LSP but now I have all the problems that you mentioned 😭

I guess it will be fine once I find time to actually wrap my head around it but migration from vim to nvim is definitely more than just a hot-swap 😕

@realestninja I have not e.g. used auto-complete in my life. It slows down the phase to the level that I actually need to understand what I'm doing, which over longer period of time results in deeper understanding because you actually have study also the API documentation. Downshifting in production pays back with a huge interest, and usually tends to result more mature software.

@realestninja Even macOS stock installation has vim right off the bat.

@realestninja @jarkko Not a fan of LSP integration myself, but there are clients for Vim you could try:

- https://github.com/prabirshrestha/vim-lsp
- https://github.com/yegappan/lsp

The first one should be neovim-compatible as well, so you could try it out with your existing config.

@AndrewRadev @realestninja Well it took me about 30 minutes to rewrite a vim config as i used already quite minimal set of plugins. I know my way with Vimscript as I've used it 20+ years.

I did add 'prabirshrestha/vim-lsp' and 'mattn/vim-lsp-settings' so that i can check at some point if they are usable with Rust. If they do less but the overall experience feels more "stable" than then it might work ;-)

With Linux kernel tree any LSP is pretty much useless, as any time I change kernel config I need to also re-generate a new JSON file. I use ctags because it can carve the whole kernel tree and does not care about the configuration.

@jarkko @realestninja Same, I'm very happy to rely on ctags. My issue with LSP is more about it *pushing* code changes to me, rather than being essentially a pull-based database.

For Rust, the usefulness is limited by how long it takes for rust-analyzer to start. With ctags, I can jump to identifiers immediately after opening a file, and if I rely on LSP, I have to wait for a looong time before it gets there.

@jarkko @realestninja

My hot take is that LSP is such a crappy protocol it'll be dead in 5-10 years, but we'll see. Either way, I find it disappointing. It basically turns Vim into an IDE in the bad way: makes it as slow and clumsy as one.

As an example, here's me manipulating rust imports: https://www.youtube.com/watch?v=4yRGh0SGVok

If you wanted to do this via "code actions", you'd have to select what to do through some generic UI, and it only splits/merges two imports at a time. Kills all flow.

I can also feel how much snappier vim is given that it does decouple UI and the editor. It is kind of thing that in architecture it is for sure fancy BUT the problem comes from that as a user it can only cause more latency.

I prefer modular code-base over modular run-time :-)

If you pile that up with LSP you have decouple text editor managing decoupled static analysis, i.e. two layers of IPC at run-time, which is crazy IMHO. And since I use mostly the terminal, being e.g. able to integrate to vscode has total zero value for me.

I added the vim LSP shenanigans because I want to see whether it feels different when the editor stack is more stable and simplified. I give it a shot for Rust.

@AndrewRadev @realestninja IMHO plugin based system similar to VST3 and CLAP in audio could be much more ideal architecture. Editor can eg then decide how to organize threads and can have a clock and scheduler which can orchestrate dynamic or even real-time behavior.

@AndrewRadev @realestninja And a C lib could be then provided for ”LSP host” which would be trivial to integrate to any text editor.

@AndrewRadev @realestninja what works in digital audio workstations can be claimed to be work also in text editors because both are model data editors for different type of artifacts.

@AndrewRadev @realestninja and both expect real-time feedback when the data is stimulated by the user 😅 so essentially same piece of software

@AndrewRadev @realestninja IPC and client-server decoupling = ridiculously overrated and zero gain for the end user