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'm working on a project that might allow at least 90% or higher compat here: https://github.com/tjdevries/vim9jit
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.
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.
I’ve been using only stable Vim and Neovim and have not had either of them crash on me that I can remember.
I'm not sure I understand what you're missing from neovim-qt?
https://github.com/equalsraf/neovim-qt
I suppose maybe we have diffuse cases - but I'm fairly certain I'm running qt neovim, and not nvim in a terminal - and I'm not aware of any issues?
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.
Ah, and it seems the (released version of) QT gui doesn't support ligature fonts yet. The FiraCode website says it works with NeoVim-gtk: https://github.com/tonsky/FiraCode#user-content-editor-compa...
Maybe I'll give that another go ...
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.
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.
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...)
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.