Live data from Hacker News

Neovim 0.9

github.com

61–70 of 106 posts

Re: Neovim 0.9

#61
post #25

After hacking around with various Neovim "frameworks" I decided I want my text editor to but just that and no more so switched back to Vim and MacVim. The improvements to Vim's scripting language were icing on the cake.

You can use Neovim without a framework. In fact, for the most part Neovim will work as-is with a .vimrc written for Vim (there are some options that are specific to Vim or Neovim, but not many, as both projects port features from the other).

Re: Neovim 0.9

#62
Id gotten busy at work and was using vscode because it was very easy to set up and use, but I never really liked it.

Recently had some downtime and finally got around to setting up nvim and writing a config for it to get an IDE experience from it, and I love it!

Probably the biggest pain-point was wrapping my head around all of the plugins and config needed for language server completion, but overall configuring it was a good experience.

Really happy to see the .9 release out, as I've been using the daily builds for a while now

Re: Neovim 0.9

#63
post #42

Since I've learnt vimscript and am relatively happy using it, what's the advantage of writing plugins in lua for neovim?

Neovim uses LuaJIT on most distributions (or when building from source), which is substantially faster than Vimscript. Although this only really matters in computation-heavy plugins.

The only other "advantage" is that the Neovim development team is 100% all in on Lua, and Vimscript is essentially in "maintenance mode". We still port patches from Vim, but even Vim has moved on to Vim9script, which Neovim has no plans to support, so traditional Vimscript is very likely not going to see any improvements from either Vim or Neovim.

Re: Neovim 0.9

#64
post #39

I have tried many times to switch to Neovim, but I keep coming back to VS Code. 1. I can't create configs myself. 2. Astro, Lunar ... all break at sometime.

Agreed. Neither VS Code nor VS Codium (my preferred variant, telemetry-free) have ever broken my setup with an update, something I can’t say about NeoVim or Emacs.

I've had one vanilla vim breakage in over a decade of use. A common pattern I see that inhibits vim usage is:

- Using too many plugins without understanding all that vim has to offer.

- Cargo culting configs instead of building up little by little.

- Trying too hard to rice vim in appearance without adding meaningful utility.

The same applies for Emacs. Vim and emacs are powerful editors not controlled by corporations, have succeeded for decades when other editors have floundered, can run in any basic computing environment/terminal, and are logically present in many Unix tools. Like all of software engineering, a deeper understanding of the system you're using pays huge dividends in the long run.

In short, take the time to learn one of these editors in it's basic form and then nurture a small config that can go a long way, and you will find success.

Re: Neovim 0.9

#65
One feature I'm personally excited about is the "undeprecation" of the 'exrc' option, which allows project-specific configuration.

Vim (and thus Neovim) has had the 'exrc' option for a long time, which loads any .exrc or .vimrc (or in Neovim's case, .nvimrc) files in the current directory. However, it does this unconditionally, which is obviously a bit of a security concern as a random .vimrc file could contain arbitrary code. For this reason, Vim recommends not using this option and Neovim even went so far as to mark it deprecated.

In this release, Neovim adds the concept of a "trust database", which is used for the 'exrc' option. When 'exrc' is enabled and a .nvimrc or .nvim.lua file is found in the current directory, Neovim will ask the user if the file is trusted (with the ability to first view the file). The file is only executed if the user explicitly marks it as trusted. Because this solves at least the most egregious security issues with the 'exrc' option, it is now marked undeprecated in Neovim.

I have been using .nvim.lua files for project specific configuration to great effect at work. Hopefully others find this feature useful as well.

Re: Neovim 0.9

#66

Earlier quoted context omitted.

> moving to neovim entails almost zero switching friction As a counter-counterpoint: I tried switching to neovim a couple of weeks ago, and gave up after half a day trying to get syntax highlighting working.

Strange considering neovim has syntax=on by default and it's not even needed in the config. What distro are you using?

I love that the usernames of the two parent comments are so fitting:

  plugin-baby: (complicated setup?) I see errors

  worksonmine: WFM
No disparagement intended. I'm sure you're both right.

My vim config is simple, and neovim handles it well. Including syntax highlighting (some custom). I don't like some of the defaults as much as what shipped with vim, but I know I could configure them out if I cared enough.

Re: Neovim 0.9

#67
post #8

I just realised that I'm using Neovim despite there are no nvim-specific plugins in my config (CoC covers most of my needs), and I don't use lua. Still is feels like Neovim is more stable and faster than the regular Vim somehow. Plus it has much better defaults.

I use default vim, I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim. I have also not found any neovim functionality that sells neovim over vim. Vim is fast enough that I have never even thought about it's speed. With term, termdebug, fzf, ripgrep, and ALE with LSPs and Vim's excellent built in support for auto-completion, tag browsing, and cscope, there's really nothing I can't do in another editor I can't do faster in vim and as a bonus I find that I know more about regular expressions than most IDE programmers.

Re: Neovim 0.9

#68

I've really tried to move from vim to neovim for a long time and spent many hours trying to configure it to behave like vim, but every time I try it breaks in unexpected ways or it hungs up, while vim for my workflow never flinks. I hope that they'll reach a 1.0 soon where things are more stable.

That's odd, because neovim is a fork of vim, not a reimplementation. What broke for you?

And forks diverge... in the case of neovim by tens of thousands of LoC. In what way is forking a stable product a guarantee that the fork will remain stable?

Re: Neovim 0.9

#69
post #8

I just realised that I'm using Neovim despite there are no nvim-specific plugins in my config (CoC covers most of my needs), and I don't use lua. Still is feels like Neovim is more stable and faster than the regular Vim somehow. Plus it has much better defaults.

I use default vim, I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim. I have also not found any neovim functionality that sells neovim over vim. Vim is fast enough that I have never even thought about it's speed. With term, termdebug, fzf, ripgrep, and ALE with LSPs and Vim's excellent built in support for auto-completion, tag browsing, and cscope, there's really noth…

>I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim.

I hate to break this to you, but Vim itself is in the process of converting its runtime files into Vim9script (which is Vim specific), and many new Vim plugins are also being written in Vim9script.

Neovim has always supported "traditional" Vimscript, and has ported all runtime file changes from Vim (think filetype plugins, syntax highlighting, etc.). In fact, we explicitly request that any runtime file changes first go through Vim precisely because we want to keep the two projects aligned. But the more that Vim transitions to Vim9script, the less can be shared between the two projects. So unfortunately the "fracturing of the ecosystem" is not specific to Neovim.

Re: Neovim 0.9

#70
post #6

For people who have used helix and neovim recently, how do they compare?

Note: I used nvim daily before using helix, but only used the basic features and used lunarvim as my config.

I started using helix a few months ago because of the batteries included zero config language server setup, i have one line in my config and that is the theme, thats it, just install the language server [1] and you are ready to go.

But I stayed for the kakoune model. Yes, it is different than vim, yes it may not be for you, but to me it feels so much superior, i feel way more productive with the kakoune way. I guess i had the advantage of not having vim keybindings (except the most basic) in my muscle memory. I never really got warm with the more "advanced" vim keybindings. But in helix it is so easy to learn them. You either have a popup that shows you the next available key and what it does or you have `Space + ?` Where you can fuzzy find commands and their corresponding keyboard shortcut. Helix took that huge learning curve I had with (n)vim and turned it into learning by doing and their little tutor at the beginning.

With nvim I used lunarvim config, as I didn't want to roll my own config and it was the best I could find, and I tried all the most popular configs. They always updated something, they often broke, they felt bloated (compared to helix or plain [n]vim) and most importantely I didn't really know whats happening under the hood. With helix I only need to update my languageservers (which get automatically updated by my system package manager) and there was no need for me to touch the config files except setting the theme to one of the themes that it shipped with and I have more the feeling that I know whats happening under the hood.

Except a file tree instead of a fuzzy file picker I don't miss anything, I don't have any need for plugins, as everything I personally need is already in there.

[1] https://github.com/helix-editor/helix/wiki/How-to-install-th...

Post reply on HN