Live data from Hacker News

Neovim 0.7 Released

github.com

161–170 of 220 posts

Re: Neovim 0.7 Released

#161
post #133
post #101

Earlier quoted context omitted.

I came from coc.nvim and switched to the native LSP when it was released on nightly. For a while I was using VSCode and came back to nvim and switched back to coc.nvim. I found that the native LSP's community to be too quickly changing. Plugins that were necessary earlier weren't, while new necessary plugins came into play. But, coc.nvim was steady chugging along and my old settings file worked out of the box. I'm al…

Same for me, coc.nvim community is rock solid whereas native LSP requires more configuration and is much less reliable version-to-version

> is much less reliable version-to-version

Source? We have an extremely extensive test suite for the built-in client that must pass for every merge, and we currently have ~30 open issues on the issue tracker (with a good chunk of those being feature requests).

Re: Neovim 0.7 Released

#162

I will never understand why people choose VSCode/Jetbrains over a terminal based editor. I can edit the kernel with clangd and get hover reference, autocomplete, go to def, ref, dec, smart refactor, and that's on top of being able to easily jump and fix lint/bugs using Vim's already great support for parsing compiler errors. With term added (which is a core Vim feature) it also has excellent support for gdb debugging…

> I can use my editor over ssh and edit anywhere, I don't need a GUI to even be installed on the system where I have all of my cores and RAM for compiling the kernel,

I can use VS Code in the browser: https://github.com/coder/code-server

> it starts up instantly,

I launch my editor once a day. Why do you need to keep killing and starting your editor?

> and it's completely free and open source,

OK, so is VS Code, or at least the OSS version, which has all the key features anyway.

> not driven by a corporation,

So this is your philosophy.

> and there's decades of documentation on how to use it.

Most of it out of date, probably.

> I guess it's the systems developer in me

Guess what? I'm a systems developer too! I also work on the kernel! But I use VS Code.

> that can't fathom someone that wants to use a tool to make a living without understanding it fully and being able to tweak it to their exact liking over the course of their entire career

VS Code is open source, so there's nothing stopping me from diving in if I want to. And it's also highly extensible.

Now that I've answered all the supposed benefits you list about (neo)vim, I have one question:

Can (neo)vim show text in two different font sizes? Or fonts? Like, what if I want my documentation popups to show up in a sans-serif font? No, don't tell me I have to open up the documentation in a browser or whatever. I want it in the popup.

Re: Neovim 0.7 Released

#163

Earlier quoted context omitted.

Neovim does bundle an LSP client.You can launch and attach with ~6 LoC. See `:help lsp` https://paste.sr.ht/~mjlbach/1a1df5cd61627e87ea4c4355a0473bf...

I did not know about this. Thanks!

Of course :) Lspconfig adds an autocommand that does this for you when it detects the filetype, and includes the start commands (that's it, all the other functionality is in core.

Re: Neovim 0.7 Released

#164
post #146
post #92

I moved to Neovim from Vim based on the recommendation from my 16 year old :). He also suggested https://nvchad.github.io . NvChad was great in setting up the Neovim configuration with LSP for Ruby and others. Much better experience than Vim.

Could you share your nvim config for Ruby? There are a lot of examples for Vim but found very few up to date for nvim.

This is a good example config to get started with nvim:

https://github.com/nvim-lua/kickstart.nvim

Re: Neovim 0.7 Released

#165

Earlier quoted context omitted.

> One use case for the new remote functionality is the ability to open files from the embedded terminal emulator in the primary Neovim instance, rather than creating an embedded Neovim instance running inside Neovim itself. Hmm, if I type "git commit" within the terminal, is there some value of $EDITOR that would make it launch a buffer to edit the commit message, then finish when I close the buffer? (and if so, are…

I'm not sure if I understand you, but with EDITOR=nvim it'll do just that. To "commit" w/ the message you have in editor, ZZ. To abort, use :cq

That's a separate nvim instance within the terminal of the outer nvim instance. If I'm understanding this feature correctly, the idea is that instead of that, you make the outer nvim instance do stuff. Then pasting back and forth between buffers works better, etc. It wasn't clear to me from this short blurb though if that includes blocking for the buffer to be handled and then signalling success or failure to the caller. (or for that matter if I'll remember the mechanism for it if there is one. I operate on muscle memory and might just stick with the tiny editor within the bigger one. But I'm curious anyway.)

Re: Neovim 0.7 Released

#166

Earlier quoted context omitted.

I'm not sure if I understand you, but with EDITOR=nvim it'll do just that. To "commit" w/ the message you have in editor, ZZ. To abort, use :cq

That's a separate nvim instance within the terminal of the outer nvim instance. If I'm understanding this feature correctly, the idea is that instead of that, you make the outer nvim instance do stuff. Then pasting back and forth between buffers works better, etc. It wasn't clear to me from this short blurb though if that includes blocking for the buffer to be handled and then signalling success or failure to the cal…

Oh, I see. I got derailed by the usage of terminal to refer to three different things :)

Re: Neovim 0.7 Released

#167
post #149
post #70

Earlier quoted context omitted.

I'm a dev that spends 90% of his computer time with a JB IDE open and I'll give you my perspective on it. It just works out of the box (or with a couple of 1-click install plugins) for practically all my use cases. * I mostly write Kotlin/Java for backend, desktop and Android projects. JB has that covered: Gradle integration, refactoring, navigation, dependency updates, documentation viewer, visual git log/diff/merge…

You're paying about a minute every time you have to wait for your IDE to start. That quickly adds up.

<15 seconds, yes. Once a day in the morning when my machine boots and I'm brewing my coffee.

Re: Neovim 0.7 Released

#168

I did a brief write up on some of the biggest new features here: https://gpanders.com/blog/whats-new-in-neovim-0-7/

Seems to be missing one of the bigger changes: support for python 2 has been completely dropped in favor of python 3.

It's always fascinating how differently people read the same text. I was just here browsing comments about the python2 drop after noticing the headline of the changelog:

> BREAKING CHANGES

> Support for Python 2 is dropped. For Python 3, the minimum supported version is 3.6. Legacy :pythonx commands are still available, and always uses the python 3 provider.

Re: Neovim 0.7 Released

#169
post #133

Earlier quoted context omitted.

Same for me, coc.nvim community is rock solid whereas native LSP requires more configuration and is much less reliable version-to-version

> is much less reliable version-to-version Source? We have an extremely extensive test suite for the built-in client that must pass for every merge, and we currently have ~30 open issues on the issue tracker (with a good chunk of those being feature requests).

Yeah I can second this. I've been using native LSP since 0.5 nightly and it's been nothing but solid. The only thing that occasionally gave me issues were tree-sitter crashes (unrelated to LSP), but even those seem to have all been fixed by now.

Re: Neovim 0.7 Released

#170

I will never understand why people choose VSCode/Jetbrains over a terminal based editor. I can edit the kernel with clangd and get hover reference, autocomplete, go to def, ref, dec, smart refactor, and that's on top of being able to easily jump and fix lint/bugs using Vim's already great support for parsing compiler errors. With term added (which is a core Vim feature) it also has excellent support for gdb debugging…

I like using vim as an editor. I don't bother with janky plugins that require some arcane blood ritual to install, configure, and be invoked. I'm not going to go through the trouble of setting up vim as a java ide when intellij does that intuitively out of the box.

If I just need to edit a file, or view it, I'll often use vim. If I need to sit down and actually code? Intellij every time.

If vi had never existed, and you introduced it today, people would think it was some sort of april fools joke of an editor. It is the least intuitive and user friendly piece of software I've ever used. The only reason I continue to do so is because I've learned it's quirks and it's stockholm syndrome now.

Post reply on HN