Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neovim v0.5

github.com

Post reply on HN
Print view View original

101–110 of 213 posts

Re: Neovim v0.5

#101

Post by kzrdude »

prince781 wrote: post #52
gen220 wrote: 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…

> This feels like a move away from plugins and into monolith territory, which feels like a big step. I don't consider LSP to be a monolith. You still have the decentralization of language server development. Rather, LSP is just a standardization of what we have come to expect from editors interacting with plugins. And because the standard is modular in its features, the barrier to entry for new language servers and e…

Well, VSCode has a controlling position in the LSP ecosystem, so we literally have microsoft looming over it.

Re: Neovim v0.5

#102

Post by thayne »

blindseer wrote: post #38
gen220 wrote: 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 l…

> Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal.

This goes back to my biggest complaint with the vim ecosystem (and emacs has the same problem): no dependency management. Almost every plugin has to be self contained, because if you depend on another plugin, then you need to rely on you users to manually install that plugin.

Re: Neovim v0.5

#103

Post by thayne »

typon wrote: post #83
fernandotakai wrote: post #51

Earlier quoted context omitted.

>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 how would you compare to nvim? i tried vsc with a vim plugin and it was just... painful.

VS Code is an awful editor in general. I don't understand how it's so popular. Maybe it's just me but I don't like having 300ms lag between every action I perform on my editor. The vim emulation is a joke. Onivim's vim emulation is great.. Because it's literally using libvim. It's also very snappy. But thats where the advantages end.

> I don't like having 300ms lag between every action I perform on my editor

Well if you are used to IDEs that also had that kind of lag...

Re: Neovim v0.5

#104

Post by sagarm »

wolverine876 wrote: post #70
_benj wrote: post #42

Earlier quoted context omitted.

Tbh, that’s how I call it but it’s just having incremental search enabled. That will highlight search/replace matches and the using s/ / That allows me to see what my regex matches. So I can start typing ^d*\. Hello and that would match any start of line digit followed by a dot and the word hello. I still have a lot to learn there but just that has been incredibly useful for me. Hope that makes sense

Yes, thanks. That's not what I thought you meant, but it suggests a great idea: Something that gives visual feedback as you construct regexes. I'm not sure that incremental search isn't sufficient, however.

That's exactly what NeoVIM supports: you get a live preview of searches and replaces. The behavior can be enabled with ":set inccommand=split" (preview in a separate window) or ":set inccommand=nosplit" (inline preview).

Re: Neovim v0.5

#105

Post by ibraheemdev »

Jenk wrote: post #85
efficax wrote: post #78

Earlier quoted context omitted.

Funny, I switched from neovim to VSCode + the vim plugin. Sure, it doesn't have everything I would do with vim supported, but it's enough and overall it's a better experience

I've started using the vscode neovim plugin. It runs a headless neovim in the background so you get literally everything that both editors provide in one. It's not 100% flawless but it is damn good. I used to flip between the two anyway - if I needed a better intellisense for, say, a large typescript project, then vscode won, everything else was nvim. Now I have the intellisense of vscode ontop of neovim.

For anyone wondering: https://github.com/asvetliakov/vscode-neovim

Re: Neovim v0.5

#106

Post by junon »

systems wrote: post #87
davidkunz wrote: post #43

I love Neovim. I switched from VSCode and never looked back, it's just so much more efficient to just do everything with your keyboard. In case someone is interested how to do the things you're used to from VSCode, I created some videos: https://youtube.com/playlist?list=PLu-ydI-PCl0OEG0ZEqLRRuCrM...

I am not sure how this is possible Editors like Vim, Emacs or VSCode are all about the plugins I use emacs for org mode And VSCode for everything else, because simply most proramming languages have their main plugins on VSCode The only way you can move from VSCode to neovim is, if you dont care about the plugins Why would you VSCode if not for the plugins

Neovim has plugins...

Re: Neovim v0.5

#107

Post by ibraheemdev »

MaxBarraclough wrote: post #25
gen220 wrote: 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…

For anyone else wondering: • LSP means Language Server Protocol [0] • ALE means Asynchronous Lint Engine [1] [0] https://microsoft.github.io/language-server-protocol/ [1] https://github.com/dense-analysis/ale

And, ALE has LSP support.

Re: Neovim v0.5

#108

Post by nerdponx »

gen220 wrote: 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…

Having LSP and Tree Sitter in Neovim is less "monolithic" to me than having Netrw.

Plus, the rest of the application is becoming increasingly modular, not less so.

Re: Neovim v0.5

#109

Post by ibraheemdev »

_benj wrote: post #48
ssklash wrote: post #45

What is the value proposition for moving from vanilla vim to neovim? I see all the features on the neovim repo, but almost all of them seem aimed at developers rather than users. I've considered switching, but I'd have to move to a .nvimrc or something, update my install scripts and Ansible, etc., and I'm not sure what I'd gain from it other than "extensibility". If there are concrete benefits for normal usage, I'd b…

For me it was the lua config file. Now tweaking vim to the behavior I want is no longer learning an obscure language but figuring out what is the behavior I want and coding that using lua and the vim api. With the lua language server vim’s api is very discoverable!

Lua is much nicer for scripting, yes, but support is not there yet. There are a couple missing APIs, and just some overall verbosity that is still being cleaned up and worked on last I checked.
Post reply on HN