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!
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 :)
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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 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.
>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 :)
> 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.
>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).
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.
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.
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!
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'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.
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).
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!
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.
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.
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?
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.
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).
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.
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.
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?
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.