Live data from Hacker News

Neovim 0.7 Released

github.com

181–190 of 220 posts

Re: Neovim 0.7 Released

#181
post #102

Earlier quoted context omitted.

I absolutely want to learn VIM but saying it's only a weekend is plain misinformation. We're definitely looking at months of gradually building new habits.

I think the difference between your and the other opinion is what does "learn vim" mean? Is it enough to know how to enter insert mode, make an edit, then save and quit? That's easy enough to learn in a weekend. Or is it learn how to edit efficiently using the various vim commands? That will indeed take much longer than a weekend. (Even getting it configured just the way you want to will probably take more than a wee…

> Is it enough to know how to enter insert mode, make an edit, then save and quit? That's easy enough to learn in a weekend.

That's Notepad level usage, you don't gain anything from it.

Re: Neovim 0.7 Released

#182
I really wanted to love nvim, because I think that some philosophies it tries to follow better match my way of thinking. However, I tried several times to configure it to match 1:1 my vim config and to stick to it, but there are several edge cases that vim solves better. Additionally, nvim with my workflow crashes sometimes, while vim doesn't.

Re: Neovim 0.7 Released

#183

People who have tried both vim and nvim: - I have a theory that using `coc.nvim` is still the superior solution even compared to a native LSP. Why? Cause we can siphon from the huge man-hours of development and polish that M$ has put on VSCode. Every time they tweak VSCode, we at downstream, enjoy the benefits. Am I wrong in my assessment? - Vim's regexp-based syntax highlighting is annoying. So I think nvim+tree-sit…

I like both COC and CMP (native). COC is way easier to set up and the default config is fine. CMP is lighter and more configurable, and it works really nicely with luasnip (my snippet engine of choice). Under the hood they both use the same LSPs, but COC pulls them down and sets them up for you.

Theoretically, we could build a plugin that does all automatic setup like COC, but then uses the built-in LSP to do the actual work. nvim-lspconfig already does part of this job - configuring the LSP, as long as the server is already installed. Personally, I prefer the system package manager taking care of the servers, rather than yet another package maintenance system.

Re: Neovim 0.7 Released

#184

I really wanted to love nvim, because I think that some philosophies it tries to follow better match my way of thinking. However, I tried several times to configure it to match 1:1 my vim config and to stick to it, but there are several edge cases that vim solves better. Additionally, nvim with my workflow crashes sometimes, while vim doesn't.

As someone who just started using nvim, and assumed that vim was identical (or close enough to it that it can just be considered identical), what are these edge cases/differences?

Re: Neovim 0.7 Released

#185

Earlier quoted context omitted.

Copying from the other comment: I remember vanilla vim doing some weird stuff, like leaving the buffer open even though I've exited the shell, requiring me to close it manually. I don't know if it's been fixed since.

There is an option to close the terminal buffer when the terminal process exits, e.g., `:term ++close `

Another poor default option choice in Vim compared to NeoVim.

Re: Neovim 0.7 Released

#187
post #28

Earlier quoted context omitted.

Why wouldn't you set the makeprg and have it populate the quickfix list instead?

Because lazygit doesn't really work that way? Because running tests doesn't necessarily play nice with quickfix? I do set the make program to build and get errors via the quickfix when there isn't a good lsp server for the language. When there is an lsp server for the language, why bother with a special make command? - the same info is just populated inline for you.

What do you mean by "play nice"?

I tend to use quickfix lists because I can edit/filter/persist them; so for example I'll have some tests/warnings but won't care about them for the moment but then rerun the command and get the diff and navigate to that.

It's fairly complicated to script the same using the LSP api.

Re: Neovim 0.7 Released

#188
post #54

I think Helix does a lot right on the "initial configuration" front. It comes with LSP and treesitter configured out of the box. Neovim on the other hand is heavily customizable, but you also have to do this for awesome functionality

I installed helix a few days ago and I realised that I've been using my neovim setup with much higher input latency than I'd like. I'm not sure which plugin is responsible for the increased typing latency or if there's an easy way to find out.

I wish helix had a mode where its keybindings become the same as that of neovim for easier transition. After years of using (neo)vim, it's almost impossible for me to switch to a different set of modal keybindings. I always ended up pressing x to delete characters in helix which, in turn, ended up selecting the entire line.

Re: Neovim 0.7 Released

#189
post #179

Earlier quoted context omitted.

It's much more than 1% though.

That's a claim no real study ever has measured to any truly scientific degree. So it's just a claim.

Just as 1% is just a claim. At least my claim is not as absurdly specific.

Re: Neovim 0.7 Released

#190

Earlier quoted context omitted.

I like both COC and CMP (native). COC is way easier to set up and the default config is fine. CMP is lighter and more configurable, and it works really nicely with luasnip (my snippet engine of choice). Under the hood they both use the same LSPs, but COC pulls them down and sets them up for you.

Theoretically, we could build a plugin that does all automatic setup like COC, but then uses the built-in LSP to do the actual work. nvim-lspconfig already does part of this job - configuring the LSP, as long as the server is already installed. Personally, I prefer the system package manager taking care of the servers, rather than yet another package maintenance system.

lspconfig maintainer here, minor info dump:

Lspconfig currently has 3 parts, the default settings for the servers, an implicit project detector to trigger when to launch the servers (conditioned on filetypes and some patterns), and the infrastructure to manage launching/shutting down/attaching buffers to servers as you open files within the same project.

Eventually we'd like parts 2 & 3 to be in core as a "projects" module, leaving separate "project patterns" and "server settings" as mostly metadata containing repositories.

That would open the door for third party plugins to create customized project templates which map keybindings, set formatexpr, pass custom server settings, etc. similar to how coc.nvim has coc-pyright, coc-gopls, etc. These plugins could also handle installing language servers automatically should they choose to offer that.

There's also nvim-lsp-installer, but I really don't like the approach it takes of hijacking lspconfig's setup.

Post reply on HN