Could someone sell me on why I should switch to this from regular Vim?
The improved tree-sitter code parsing also allows for stuff like this which you won't find fully implementable in mainline Vim yet:
31–40 of 213 posts
Could someone sell me on why I should switch to this from regular Vim?
The improved tree-sitter code parsing also allows for stuff like this which you won't find fully implementable in mainline Vim yet:
Bundling in a bunch of plugins[1] feels semi-cheating for shipping a new release, but I'm ok with it. I do get a bit of a monolithization vibe, and it kind of scares me to think that neovim might get stuck with some ever-ossifying codebases it shouldn't have pulled in, but overall I think the gains of building a more rich, integrated, baseline editing environment probably justifies the damage of consolidation/picking…
vim is bash. nvim is zsh if not fish.
Or maybe vim is RHEL, and nvim is Fedora
Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach? While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor? For context, using ALE, I'v…
From my understanding, it’s also an opt-in feature, so you are free to use anything other language client or no language client at all.
But I agree with you that Neovim is gradually becoming more monolithic (though I believe it’s still very snappy and light). I’m pretty happy about it, though.
Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach? While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor? For context, using ALE, I'v…
For those out there trying to "learn" vim, give neovim 0.5 a try! I've been using neovim HEAD (0.5 pre-release) for a while and it has been awesome. It all started with this config [0] and from there and haven't tried (as before) to join a vim cult but instead to use it as a tool that works for me (i.e. use mouse scroll to browse around, use arrows on insert mode, and other vim sins) Little by little I've been lookin…
Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach? While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor? For context, using ALE, I'v…
I would actually LOVE to see VIM with NerdTree, File/text searching, lsp and first class git support baked in and integrated well without need of tuning something in your .vimrc file every weekend.
Could someone sell me on why I should switch to this from regular Vim?
Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach? While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor? For context, using ALE, I'v…
1) nvim's built in lsp client is entirely in lua and afaik none of it is related to the nvim core. It is not inconceivable to just move it to a plugin but pretty much everyone will have to depend on it. I think for something as powerful as lsp, it might as well be bundled.
2) the built in lsp client in lua is EXTREMELY customizable and lightweight. In fact, a lot of useful features are enhanced or extended with plugins. Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal.
3) The people that built the lsp client are extremely passionate about it and have contributed to neovim. tjdevries has some youtube clips and twitch stream clips where he talks about why this is a good idea. One thing that was mentioned during the stream today was that luajit and using libuv / LUV makes you feel like why not write an LSP client in nvim lua.
I personally think since it is so lightweight and since it is all in lua, it's awesome to have. And the next big thing can also be added to nvim base in lua without too much "cruft".
Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach? While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor? For context, using ALE, I'v…
Also I'm just too old to learn the whole Lua API.. That's not something I hold against nvim, but it's a reflection on my laziness? I just want a good vim based experience and nvim did that for me.
Btw, I paid for Onivim2. Was surprised by its snapiness but it's pretty useless as a working editor if you want equivalent features to nvim
Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach? While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor? For context, using ALE, I'v…
I would actually LOVE to see VIM with NerdTree, File/text searching, lsp and first class git support baked in and integrated well without need of tuning something in your .vimrc file every weekend.