Live data from Hacker News

Neovim v0.5

github.com

31–40 of 213 posts

Re: Neovim v0.5

#31
post #21

Could someone sell me on why I should switch to this from regular Vim?

There's a few really cool things. The built in LSP is pretty clean compared to clunky nodejs or python plugins which I've found to clog down on huge codebases. The syntax engine has been improved by a tree-sitter algo, so it's way more robust with the syntax hilighting. And while I haven't messed with this yet you can do the whole config file in Lua now, which sounds pretty powerful.

The improved tree-sitter code parsing also allows for stuff like this which you won't find fully implementable in mainline Vim yet:

https://github.com/nvim-telescope/telescope.nvim

Re: Neovim v0.5

#32
post #8

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…

This isn't that big of a deal. vim is installed by default on all mainstream unix systems if not installable on any system of your choice. Neovim should be a more comprehensive vim.

vim is bash. nvim is zsh if not fish.

Or maybe vim is RHEL, and nvim is Fedora

Re: Neovim v0.5

#33
post #19

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 actually started using Neovim builds from master to get access to built in LSP before this release. It’s faster and lighter weight than any other LSP client I’ve used (I have used vim-lsp and languageclient-neovim in the past).

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.

Re: Neovim v0.5

#34
post #19

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.

Re: Neovim v0.5

#35
post #10

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…

To clarify for people unfamiliar, all of that is common to Vim and Neovim except maybe visual regex - what is that?

Re: Neovim v0.5

#36
post #34
post #19

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.

And I would hate to see NerdTree baked in. So I'm glad we have choices via plugins.

Re: Neovim v0.5

#37
post #21

Could someone sell me on why I should switch to this from regular Vim?

Originally the big selling points (IMO) were that it supported async plugins and an embedded terminal. Vim added both of those in version 8. For whatever reason this issue bugs me enough to keep me from switching https://github.com/neovim/neovim/issues/1496. I tend to open things like :!tig and neovim can't do it.

Re: Neovim v0.5

#38
post #19

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'll give you my perspective (I'm just an average user):

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

Re: Neovim v0.5

#39
post #19

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 have been an nvim user for the past few years now. I tried the whole modern nvim experience with Telescope, built in LSP and other Lua based extensions.. My conclusion is that my current setup with Ale, FZF + silver searcher, clangd/pylint and Deoplete is way faster, less buggy, albeit harder to setup.

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

Re: Neovim v0.5

#40
post #34
post #19

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.

I know it sounds snarky, but at some point of vimrc complexity it’s worth considering just switching to vscode with the vim extension. It can use neovim as a back end and you get mountains of features out of the box. I created vim-idiomatic key mappings to all the vscode features and extensions I commonly use. It’s not vim, it uses a shit ton of memory, and you can’t run it in the terminal, but I love it. For context, I was formerly a vim snob for 10 years. I’m also mainly a typescript guy so YMMV.
Post reply on HN