Neovim 0.9 | Hacker News Reader

Neovim 0.9

github.com

117 pointseugene_pirogov104 comments

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.

> In this release, Neovim adds the concept of a "trust database", which is used for the 'exrc' option.

This is basically how direnv and shadowenv work. So if anyone has used those, this is the same idea but it lets you layer on project-specific nvim config without shipping a whole, preconfigured nvim with your projects. Pretty cool!

Indeed. The combination of direnv and exrc is very potent.

I just use a Neovim distro like https://nvchad.com/ and I am reasonably happy. Can customize anything specific on top of that.

Congrats to the Neovim team! I know one complaint that people tend to have with nvim is that they can never get to a stable config that they don't need to keep tweaking; I used to be one of those users that kept making changes to their config but I've had a stable config for roughly 6 or so months now and I've been loving neovim and the fact that it's personalised exactly to my liking. So what I'm trying to say is that there's hope for those who are still in the depths of the configuration rabbit hole :)

Any chance your config is public? I always find cool new stuff when I look at other people’s nvim configs

You can check out these public configs:

- https://github.com/NvChad/NvChad

- https://github.com/LunarVim/LunarVim

- https://github.com/AstroNvim/AstroNvim

All of them have a Docker command where you can try them out in a container.

awesome-neovim has more configs:

https://github.com/rockerBOO/awesome-neovim#preconfigured-co...

Don't forget a raising star of LazyVim [0] of lazy.nvim fame

[0] https://www.lazyvim.org/

OP didn't reply, but here's my set of dot-files in case you still wanted to have a gander at someone's. You can find the Neovim configuration in the neovim directory.

https://github.com/AlexSWall/dot-files

And here is mine - it’s goal is parity with VS Code, but in a single file that’s well organized (based on kickstart.nvim)

https://github.com/weakphish/dotfiles/blob/master/.config/nv...

Use Space vim Astrovim or Lunar vim

i actually solved this by moving my whole dev environment into a reproducible Dockerfile.

Can see it here https://github.com/hauxir/dotfiles/blob/master/devenv.sh

then i can simply run it anywhere that has docker with a curl/bash script :)

can run it by running

. <(curl https://haukur.io/shell)

in bash

Custom config is not necessary to leverage vim or neovim effectively.

This is a personal usage issue. The fact that you can customize it doesn't mean one needs to, or should.

I run with a mostly vanilla config and a few plugins and have not had to change config for years.

I would suggest everyone to use a neovim plugin manager that has a lockfile, like lazy.nvim, and check in the lockfile. This adds stability.

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.

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

I don't think the onus is on the original project to maintain compatibility with a fork. Neovim made it pretty clear from the beginning that they were going to fracture the ecosystem and now we have colorschemes in Lua that can't be used in vim... say what you will about Emacs, but at least all of their distros can run the same code.

From my perspective as a vim user, neovim has only made my life worse by splitting plugin authors into two camps without any real benefit over what we had in vim. The only good thing about neovim is it caused some nice features to be added to vim, which the neovim authors could have just contributed themselves without trying to fight for control of the ecosystem with Bram. Neovim has really just made things worse for everyone.

Probably me but I definitely sense biases in your replies.

Vim ecosystem is 'controlled' by the community not Bram. If Neovim/Lua is not good enough there wouldn't be a fracture in the first place.

The fact that Bram saw the success of Lua with Neovim but insisted on inventing Vim9Script speaks for itself. Yet you somehow manage to blame everything on Neovim.

No, that's just not how it works. The original project came back to fracture the ecosystem in response to the fork that did not do so.

the more Vim transitions to Vim9script, the less ... "fracturing of the ecosystem" [can be attributed to] Neovim.

I see what you did there.

I never looked at neovim until Vim9Script. Such a strange choice to invent and maintain a language when that energy can be put to fixing bugs or adding features. He's done amazing work maintaining vim for so long but I don't enjoy the not-invented-here mentality. It adds unnecessary complexity and potential security issues to the codebase with no real benefit.

It's his project he can do whatever he wants, but I'm planning on using this tool for the rest of my career so I went with the fork. Moving my config to XDG_CONFIG_HOME was a welcome side-effect.

How do you all install neovim on Linux? The .deb is gone with this release, which I think was the most orderly way to fit into my install. I think I'll want to find a PPA solution now. I am not a fan of installs that are not reversible.

We are stuck with the app images now it seems

I have been installing into $HOME/.local for a while now and it works wonderfully. I build from source, but it should work just as well from a tar or AppImage.

How do you uninstall and clean it up, in that case?

    rm -rf ~/.local/{bin,share}/nvim

You should get a better package manager/distro. With emerge or pacman, it's easy to find/write your own ebuild/pkgbuild, way better than adding ppas.

Fair. I'll soon give asahi a try on a refurb mac, so then I'll be try arch style package management.

Not sure if adding ppas is the problem, i think that's ok, but making packages when none exist is more of a hassle.

If you don't want an older version from your distro, it's easy to use the appImage.

    cd ~
    wget --quiet https://github.com/neovim/neovim/releases/download/nightly/nvim.appimage --output-document nvim
    chmod +x nvim
    sudo chown root:root nvim
    sudo mv nvim /usr/bin
    mkdir -p .config/nvim

To uninstall, one would delete the binary, and .config/nvim + any other folders specified in your plugin manager.

Then I'll need some other service or system that integrates it with the desktop and .desktop files. I haven't looked into that, but I see it exists.

I have a script in my dotfiles that installs neovim from source, based on a version I set elsewhere.

PPAs are available for both stable (0.7.x)[1] and unstable (this 0.9)[2] versions. I use the latter and it has worked well for me.

1. https://launchpad.net/~neovim-ppa/+archive/ubuntu/stable 2. https://launchpad.net/~neovim-ppa/+archive/ubuntu/unstable

The stable one never updated to 0.8 so it has not been of much use in that way unfortunately

You can always find the latest Neovim in Nixpkgs Unstable, modulo a week or two. Neovim 0.9 is on its way in right now: https://github.com/NixOS/nixpkgs/pull/225152

Just make sure your user's Nix profile is included in your XDG paths like so, and the .desktop files Nix installs will get picked up by your DE: https://nixos.wiki/wiki/Nix_Cookbook#Desktop_environment_doe...

If you really want to stay on top of the bleeding edge, you can use this overlay to run prebuilt copies of Neovim nightly on any distro: https://github.com/nix-community/neovim-nightly-overlay

To ensure that the Nix installation itself is easily removable and sets everything up correctly for you, use the Determinate Nix Installer for a fast and easy installation: https://github.com/DeterminateSystems/nix-installer

In case you don't want to wait for the final package to land in Nixpkgs, command for installing 0.9 from that PR branch after using the above Nix installer is

  nix profile install github:GaetanLePage/nixpkgs/neovim#neovim

which will build from source against that PR branch.

Nix can be a great complement to a stable, conventional base system like Debian for use cases like this. I hope you give it a try!

I'm not a fan of installs that aren't reversible either. That's why I don't touch any distro that fights me on that (such as one that supports .deb)

A shame they removed the .deb package. Oh well, I use gvim as my daily driver anyway.

I began utilizing Vim approximately three decades ago, and experiencing a contemporary tool like Neovim still feels incredibly astounding.

As a counterpoint of sorts, if you are accustomed to vim, moving to neovim entails almost zero switching friction.

Everything works just like it's supposed to. In fact sometimes I get neovim instead of vim (when I run "vi" from the shell) and I don't even notice.

I have a fairly simple vim config.

I'm sure this means that I'm missing out on all the great new things about neovim, and maybe I'll get there some day. But I am happy with how vi/vim/neovim work reliably and consistently every time.

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

quesera: also fitting, as you’re happy to go with the flow :-)

Why do you use neovim when it sounds like you’re marginally less happy with it?

Ha, well, consistent with the thread here:

I don't use neovim, per se.

But sometimes when I run "vi" on one of the various systems I frequent, neovim is what I get.

It doesn't break any of the config I've set explicitly, and doesn't give me wildly unexpected settings aside from that, so I'm good. :)

Sorry, should have been more specific. I was trying to get tree-sitter working, as that seems to be the big differentiator for vim vs. nvim.

> Everything works just like it's supposed to

There are different defaults for the pane management and the terminal. The vim defaults, IMO, allow a more consistent user experience. E.g. when you are in a vim terminal and you go to normal mode to yank some stuff to put it in the other pane with the code, nvim defaults adds line numbers to the terminal that need to be cleaned up afterwards, vim just does not add them. This is just one small example, but there are several edge cases where the vim defaults behave like I would expect and nvim either does something unexpected or it lags or it crashes.

>E.g. when you are in a vim terminal and you go to normal mode to yank some stuff to put it in the other pane with the code, nvim defaults adds line numbers to the terminal that need to be cleaned up afterwards

Maybe I'm misunderstanding, but the Nvim terminal does not do this, at least by default (maybe some plugin enables this "feature"). If you yank some text from a terminal buffer in Nvim and paste it into another buffer with p, no line numbers are added.

Neovim 0.9.0 release notes: https://github.com/neovim/neovim/blob/v0.9.0/runtime/doc/new...

GitHub release page with build artifacts: https://github.com/neovim/neovim/releases/tag/v0.9.0

> EditorConfig support is now builtin.

That's great, one less plugin to install.

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.

> VS Codium (my preferred variant, telemetry-free)

Telemetry reduced -

https://github.com/VSCodium/vscodium/blob/master/DOCS.md#dis...

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.

I don't disagree, but then you shouldn't update Neovim if you are not ready for that. I'll go even farther: don't use Neovim if you are not going to write the config yourself.

Then they'll never use neovim? That's poor advice.

Vim/neovim/emacs are all tools for power users, writing your own configuration and extensions is intended. The authors of these tools have no wish to capture market share or users. Use vscode if it fits you, no one minds or cares.

Don't learn neovim (or vim) as an IDE. Learn it as an editor. Then add tricks when you are ready.

I'd suggest learning and understanding the vim way of doing things instead of trying to shoehorn the workflow you're used to from VSCode. It's a different world, and it can be really fun to explore but you have to commit.

Start small with empty config and no plugins and search the web when ever you want to do things. Yes at first it feels strange and even stupid that you search replace with '%s/oldword/newword/gc'. Then you realize sed in the terminal is the same syntax, 'sed s/old/new/g' and things start to click.

Once you're comfortable you know what you want out of the tool and what features you'd like to add. Chances are you'll find completely new ways of doing things with much more flexibility so don't limit yourself to the plugins too early. The only plugins I use today is fzf, and nvim-lspconfig.

I don't think the cost versus return ratio is that good for that. I better churn Leetcode questions and get better job

If that's your motivation it could still be useful. Almost every live coding interview I've had so far has a part where I'm explaining the magic tricks I'm performing in vim. I have to remember to slow down and explain my thoughts as I zip through the code or they will just see code moving around the screen.

For me it's mastery of my toolbox. Understanding vim pushed me further down the rabbit hole and now my computer works for me. If I help anyone my palms get sweaty as they scroll scroll scroll through the code, but I keep it to myself and remember to breath. Maybe I could do some leetcode (whatever that is) while waiting?

That's something I can do with vim emularion too right?

Part of motivation of the switch was getting a lean environment that doesn't hog resources.

No not really. Granted I've never used any of the emulators (outside of firefox) but vim is so much more than handy keybindings for editing text. It's difficult to explain and has to be experienced. And even if the integration is 1:1 it won't help with resources so I don't see the point.

Resources was my only motivation when I made the switch, had to because everything was electron and my laptop couldn't handle it. Now I'm a few years in and whenever I get tired of doing something repetitive I create a keybinding to perform that action.

A recent example is take the current filename (%) remove the extension (:r) and run it with valgrind to monitor memory usage. Bind it to <leader>vg and it looks like this:

  nnoremap <leader>vg :!valgrind ./%:r<CR>

When I hit it in the file 'my-program.c' it runs 'valgrind ./my-program' and I get the output in the built-in terminal. Very simple example but shows how easy it is to add any command-line tool you want without reaching for plugins, and integrate into your workflow instead of inheriting someone else's. Any command and combination of keypresses can be turned into a keybinding.

I understand it's not for everyone, but comparing it to vscode and judging from that perspective is missing the point entirely. I don't type letters when I edit code, I execute and compose commands, it's a different mindset.

Why not have both? https://github.com/vscode-neovim/vscode-neovim

I was using the VSCodeVim plugin, but it kept breaking. I now moved to the Neovim plugin and works great!

I'm using that but VS code is a battery and memory hog.

I sometimes use Zed but it's subpar in terms of features.

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.

What did Vim give you that Neovim didn't provide?

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

I decided not to give in to any configuration frameworks and I see them as unnecessary complexity.

Initially, I just symlinked my old .vimrc to ~/.config/nvim/init.vim and started adding if sections to configure neovim features while keeping the config backwards-compatible.

Eventually I started rewriting small chunks of it in Lua, and now I'm 100% migrated to init.lua. I think it's a little cleaner this way, but not a life changer. The real power of Lua is for plugin authors.

Perhaps by "frameworks" you meant plugin managers.

On vim, I was using vim-plug, which works fine with neovim too.

At some point I switched to Packer, which is written in Lua and is definitely more powerful. Now I would recommend Lazy instead: https://github.com/folke/lazy.nvim

Yes, it's silly that neovim still doesn't come with built-in plugin management. Installing a plugin should require 0 lines of config.

I spent a good amount of time learning vim/neovim and installed tons of plugins, but in the end I didn't see the point. Language support is still nowhere near VSCode, let alone Jetbrains products. I do all my development on a macbook so ultra low memory or being installed by default is not a requirement.

People praise vim/neovim for being small but to get any decent functionality you will end up with tons of plugins. The default vim/neovim is a fine text editor but when you need to write text you have better tools anyways. Maybe one can type fast in vim, but who is writing code limited by the speed of typing.

I like Neovim but I'm not sure their embedded vision is taking off.

You'd want their framework to end up in a very popular IDE for example, and that's just not happening.

All major IDEs will want full control over their editing component.

Because of that they won't implement "IDE-like" features such as a file explorer (I know there are plugins out there, plugin based systems are always slower and more brittle, both in the present and for updates), moving the command bar to the top, having powerful built-in fuzzy file finding, etc.

Perfect is the enemy of good, since perfect might never come and we could instead have good now or at least soon.

For file explorer and fuzzy finder, neovim does inherit netrw and vimgrep from vim. I use the netrw all the time and have never felt the need to install a file explorer plugin. vimgrep, less so since I have telescope with fzf and ripgrep, but it does exist!

A few months ago I stumbled on Astrovim which is an opinionated NVim setup. They have built pretty much exactly what I was trying to do by hand. After 20 years of flirting with Vim then going back to other IDEs I think I’ve made the Vim thing finally stick and become productive with it.

It’s partly the type of coding I do, but I’m always contributing on the DevOps side too - Dockerfiles, .env files and the like. Being close to the terminal and within a Tmux session is perfect for that type of work.

>Language support is still nowhere near VSCode, let alone Jetbrains products.

and vscode/jetbrains vim mode is nowhere near what neovim can provide. so between using a bad version of vim with features, i prefer a bit less features with more... you know, vim :)

The neovim extension for vscode embeds neovim. It doesn't perfectly integrate, but it does scratch the itch for me.

I prefer an editor that I can customize to my liking and I don't have a conflict of interest with the developers.

Same here. There's always struggle with software, so I prefer to struggle with the software, and not against it.

> People praise vim/neovim for being small but to get any decent functionality you will end up with tons of plugins.

If a writer compares VSCode to Word and claims exporting as PDF is "decent functionality" making VSCode a useless tool does he even understand what he's looking at?

You have the same language servers as VSCode, GDB is integrated and works really well. On top of that you have the entire OS and unix philosophy at your fingertips. Even with vanilla vim I have many more features than I ever had with VSCode and the likes.

It's not all about buttons and pretty dropdrowns. I agree the discoverability could be better, but that's a necessary compromise for making just about anything you'd like to do possible.

I think that, strictly speaking, this cannot be entirely true, as VS Code gets language support from the same place that Neovim does - namely from LSP servers. VS Code simply packages these up in extensions, whereas in Neovim you need to install them. Plugins exist to automate this entirely - see Mason. Yes, it is all plugin-based, but this is as opposed to extension-based VS Code.

Some of the VS Code extensions provide some nice added value, such as LLDB debugging for C/C++ and Rust, but you can actually get this in Neovim, you just need to install the extension in VS Code and then point to it from Neovim. If you dig around, you can see this in my dotfiles, linked in another comment. And this is only an issue for debugging compiled code to give nicer variable information for e.g. strings, which is quite specific.

I've also found Microsoft's recent move to Pylance from Pyright has meant a few small things aren't there for Python, which admittedly was disappointed, but again, broadly this isn't an issue at all.

Otherwise, I've not found this issue with Neovim at all.

>Maybe one can type fast in vim, but who is writing code limited by the speed of typing.

Most of the time we edit code, not write it. And this is where (neo)vim shines. You can move between places you want to modify and do so with as little afford as possible.

Language support (at least for languages I use the most) is the same as VSCode and IDEA (give or take) but at least I get to decide what do I want to get from the tool.

>People praise vim/neovim for being small but to get any decent functionality you will end up with tons of plugins.

No, these days you basically need only a plugin manager + treesitter + LSP (add a few UI plugins to your taste).

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

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.

I felt this way in the 0.7 and earlier days but since then it's been remarkably stable for me, at least.

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?

The dissonance between the lua config and vimscript config is infuriating, combined with plugins not providing default config snippets (other than copy and pasting them off the their github readme's).

>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

Could you elaborate on this? Out of the box, Neovim and Vim are extremely similar, almost identical to a first approximation (Neovim has different defaults for some options than Vim, but that's about it). The two start to diverge dramatically when you begin writing or using plugins as the extensibility/API model is quite different between the two, but I am very surprised to hear you had difficulty trying to make Neovim behave like Vim.

I try this release on debian buster:

nvim: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by nvim)

Why binary doesn't support old glibc?

You can probably get this version of Neovim to run on your Buster system with Nix, which will pull in a newer glibc in an isolated/self-contained way if its Neovim build needs it!

I left some instructions for how to get started with this in this comment, if you're interested: https://news.ycombinator.com/item?id=35482673

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

Better documentation and support. Since Lua is a well-established language, there's a larger community around it than something like vimscript. What I've heard from the community is that vimscript and its quirks are difficult to deal with, which complicates plugin development. Lua support means more complex and stable plugins, but if you prefer vimscript nobody's stopping you.

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.

None that i've seen. Everyone seems to love Lua but its a mess for a config language -- its just untyped dictionaries passed around everwhere. Spelling error in some special string keyword? Too bad.

Might as well use lisp at that point.

i'm considering hopping over from emacs but i'm not sure how to kick off an async shell command, pass the current buffer to its stdin, and write its output to a buffer. does anyone know if should i be using job_control or io.popen for that sort of thing?

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

Stating the obvious - the edit modes are fundamentally different and helix doesn't have a plugin ecosystem yet.

Helix uses the kakoune model:

vi basic grammar is verb followed by object; it’s nice because it matches well with the order we use in English, "delete word". On the other hand, it does not match well with the nature of what we express: There is only a handful of verbs in text editing (delete, yank, paste, insert… ), and they don’t compose, contrarily to objects which can be arbitrarily complex, and difficult to express. That means that errors are not handled well. If you express your object wrongly with a delete verb, the wrong text will get deleted, you will need to undo, and try again.

Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.

Source: https://kakoune.org/why-kakoune/why-kakoune.html

This is a great point, although of course vim does let you visually select before verbing a chunk of text. Useful for cases where your object spec doesn't fit into the easy categories of character/word/block/etc.

I'm not familiar with the Kakoune or Helix selection UX, but it's keystroke-economical in vim (of course).

How is this different than Vim's visual/visual-line/visual-block modes? Other than the mode now being the default behavior, that is.

As I recall from trying this out a while back, it’s different mainly in being less powerful and flexible. In [n]vim you can combine these selections with all the vim grammar, including, essentially, its text objects.

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

Helix takes (IMO) the very smart approach of making language server plugins "just work". The defaults are good enough for most use cases. This is a key friction point for new users of vim/neovim that don't want to spend days setting up an IDE like experience, and something vscode and helix get right.

It lacks a good config and plugin story though, so if you're not happy with the defaults its not great.

I also just dislike the different actions. Having everything be a selection just doesn't make sense to me compared to the vim style.

Does anyone have a TLDR/highlights of the release?

See https://github.com/neovim/neovim/blob/040f1459849ab05b04f6bb...

I'll kind of hijack this thread to ask a support question:

I often use neovim within the terminal in VSCode. Lately, I've had issues with the cursor becoming invisible while in normal mode. The line cursor works as expected in insert mode. Changing the settings for cursor style in VSCode temporarily fixes it, but the problem comes right back when I transition to insert mode and come back to normal mode. Anyone have any suggestions for a fix?

Reply on news.ycombinator.com