I'm a long time (20+ years) vim user, and neovim doesn't fit my use case. I've tried it, most recently today, to have a look at LSP and treesitter.
Treesitter added different syntax colors, but the result wasn't necessarily better than vanilla vim. More like an overly decorated christmas tree.
LSP and other "make it into an IDE" I usually turn off after a few minutes, it's more of a hindrance than a help. I mainly code in python and don't care for intellisense.
Other than that, there's 3 real showstoppers for me:
- the obsession with Lua (I personally don't like Lua much, and even to configure treesitter I have to inject little snippets of lua code into my .vimrc). You've got people even trying to rewrite their entire .vimrc in lua, which results in an enormously verbose mess if you ask me. Lua is also what drives the vim and neovim communities further apart.
- they removed gvim (which is what I use in most cases). There is no comparable third party GUI like gvim available. They're all either abandoned, unstable or simply very different with lots of bling and gimmicks.
- neovim feels less stable than vim. It just crashed on me a few minutes ago when I was trying to configure treesitter. I copy pasted the necessary snippet in my .vimrc and neovim crashes until I take it out. In the 20 years I use vim, I don't think I've ever had it crash on me. Neovim seems more of a "move fast & break things" development model, but I write code for a living so I prefer the rock solid stability of vim.
So I'll stay firmly in the vim camp. I appreciate neovim for what it did (kickstart the vim development, which was stagnating at a certain point) but I wished they had re-merged soon after that initial goal was met. Now the communities have split and are drifting ever farther apart. Soon with vimscript9 plugins on one side and lua plugins on the other, the spaghetti will be even harder to untangle.
Yeah, I've used Vim since the mid-nineties too. At first it was my "edit a config file in my RedHat 5.2" tool. Later, the more and more actual software dev I did, it became a daily driver. I am pretty sold on the "Vim way".
I have a workflow. It's hard for me to adopt new things into my worflow because my workflow works so well. I finally made the switch to NeoVim just over a year ago because I wanted to see what the fuss was about. I have to say, it's now firmly entrenched in my workflow. It's to the point where I'd be annoyed if I had to go back.
The one sticky point about your post that I wanted to highlight:
>I personally don't like Lua much
I can say that almost anything is better than VimScript... I hate every moment I have to mess around with it. The hardest part is, I don't use it for anything else so every time I dive in, I have to remember how it works. At least Lua is a multipurpose language and documentation/help are plentiful.
But, I get that the whole intellisense, popup windows, bling... those things are not for everyone. If they don't enhance your workflow, then you're never going to desire them.
I'll ignore the other parts I disagree with in this post, since it's cool to have different views but I just wanted to post that it may someday be possible to run vim9script plugins in neovim :)
Of course, vim9script isn't complete yet, so the spec isn't all the way done, but it may someday be possible to run them in neovim.
Additionally, if someone actually just wanted to port all the C code to run or has some other way to make vim9script run, neovim is not opposed to making that happen.
> Treesitter added different syntax colors, but the result wasn't necessarily better than vanilla vim. More like an overly decorated christmas tree.
The problem here is that people use treesitter to add more colours to distinguish more types of tokens. For me this is too much and the colours lose their meaning.
I recently switched to a colour scheme that only changes the colours for strings, numbers and comments. Treesitter allowed be to add very targeted minimal highlighting. For example, I know highlight the first line of a function definition. This makes it very easy to see function scopes.
We don't really need more highlighting, but meaningful highlighting. With treesitter you can do both.
Just a note on stability, you reference Neovim crashing when setting up Treesitter. That means you’re using an unstable version of Neovim as Treesitter and Lua configuration are in the unreleased version 0.5.
I’ve been using only stable Vim and Neovim and have not had either of them crash on me that I can remember.
> they removed gvim (which is what I use in most cases). There is no comparable third party GUI like gvim available. They're all either abandoned, unstable or simply very different with lots of bling and gimmicks.
I'm not sure I understand what you're missing from neovim-qt?
Thanks. I'd previously tried and failed a couple of times to get a NeoVim gui installed, mainly because I wanted to try one of those ligature fonts that display -> as → and the like. There seemed to be a few different options, in various states of being abandoned, or unpackaged, or needing libraries not in my OS, or ...
Turns out now all that's needed for Ubuntu is sudo apt install neovim-qt. Thank you for prompting me to look at this again.
However, on running it, the window seemed very wide, so one of the first things I tried was `:set columns=80` — and nothing happened. Checking :h 'co`, it looks like it's supposed to work.
Whenever I read about LSP I'm reminded of Jonathan Blow's talk Preventing the Collapse of Civilization where he talks about LSP and how it turns your single app into a fragile distributed system[1].
The sheer complexity of going from vi, to vim (and plethora of plugins), to vim + LSP is simply insane to me. It does feel like we've all lost our minds.
I didn't watch the whole talk just the part you linked. I'm sure he makes some good points. But yeah, this guy does not understand why we have lsp's at all.
An LSP is a program that parses and internalizes a project written in a particular language and serves information, diagnostics, and edits, to a generic editor. The protocol is broad enough to serve all the "smart" language-aware functions provided by full-blown IDEs.
This allows one LSP to be used in ... many different editors. The advantage to the users is obvious: if go has one standard LSP, people who use neovim, vscode, vim, emacs etc all have an interest in maintaining that one LSP and will contribute to it in various ways.
Let me give you a few reasons why not only is it fine that it's a separate process, but you want it to be in a separate process.
1. LSPs will be better written if they themselves are written using runtime and the language that they serve.
2. LSPs can potentially hold a lot of memory. Sometimes you need to manage them, and potentially even cut them off, for example if you have a few very large java projects that you're switching between. Generally if they are separate processes, you can just kill them without affecting the editor. Additionally this also means the editor itself doesn't risk a memory leak caused by a rouge LSP server.
3. Subprocess management is not that hard. The editors can do it. Neovim does it pretty well in my experience. The presenter acts as if the server is some totally separate thing that you have to manage yourself. In reality the language server process is launched, managed, and owned by the editor, and often just communicates over stdin and stdout, not that there's anything wrong with ports.
Using multiple processes to distribute work among programs that do one thing well has always been the UNIX way.
He's definitely got a point. I had some memory problem with a business calculation I was running, I needed all the memory I could get.
So I looked at the various memory hogs on the linux installation and could see that every Vim invocation had a node process hanging off of it as a child, that's the Coc code completion/language server client running. (Action => only trigger coc for certain filetypes)
And I had vscodium running too, and it had its own long lived subprocesses hanging off of it, for language support, etc.
A lot of apps are like this - humongous clusters of processes (firefox, teams, vscode, and also Vim with the right plugins...)
I agree with you when it comes to basic config. Vimscript is better for setting options, basic mappings and events. Anything more complex then that is a pita in vimscript.
Agree totally. My experience with NVim 0.5, which is what most configs require, was errors and instability all over the place. I also don't like telescope which froze nvim on me completely.
Other than that, there's 3 real showstoppers for me:
- the obsession with Lua (I personally don't like Lua much, and even to configure treesitter I have to inject little snippets of lua code into my .vimrc). You've got people even trying to rewrite their entire .vimrc in lua, which results in an enormously verbose mess if you ask me. Lua is also what drives the vim and neovim communities further apart.
- they removed gvim (which is what I use in most cases). There is no comparable third party GUI like gvim available. They're all either abandoned, unstable or simply very different with lots of bling and gimmicks.
- neovim feels less stable than vim. It just crashed on me a few minutes ago when I was trying to configure treesitter. I copy pasted the necessary snippet in my .vimrc and neovim crashes until I take it out. In the 20 years I use vim, I don't think I've ever had it crash on me. Neovim seems more of a "move fast & break things" development model, but I write code for a living so I prefer the rock solid stability of vim.
So I'll stay firmly in the vim camp. I appreciate neovim for what it did (kickstart the vim development, which was stagnating at a certain point) but I wished they had re-merged soon after that initial goal was met. Now the communities have split and are drifting ever farther apart. Soon with vimscript9 plugins on one side and lua plugins on the other, the spaghetti will be even harder to untangle.