Neovim 0.12.0
github.com
github.com
AI has made it so so easy to get into neovim and make anything work no matter how obscure it is.
The biggest benefit for me which I haven't realized how good it is with tmux and the low low memory usage. I mean I can keep EVERY project I work on open, quickly switch and maintain.
No more 10gb memory usage on a SINGLE project, no more laggy remote access, no more dreading reboots, no more wasting time.
Kernel panic? everything is right there how you left it, honestly it makes me feel so sad because the poor design of IDE's have been such a show-stopper for a LOT of good project designs that I have completely avoided due to introduced complexities that come not to mention how slow things can become.
Now I can just ssh into my pc from a laptop and work, no synchronization, no need to have a beefy laptop and incredible battery life.
I can do simple search/replace, page up/down, jump to character or delete x words, but I feel like I'm missing a lot to really take advantage of it.
Is there a tutorial or guide people recommend to become more of a power user? The only plugin I have is the Markdown editor for instance.
Also just use the mouse! Lazyvim has great support for it.
<leader>SK is your friend as well.
I feel like the habit I’ve benefited the most from on my neovim journey has been reaching for :h before doing any web search. Good completion in the command-line helps a lot there.
I'd also suggest kickstart.nvim over Lazyvim as its leaner with a primary file for configuration it is not lacking power.
Whats your source?
My mileage was quite different: last time I tried, scrolling too fast with the mouse wheel consistently caused a segfault.
Not sensible. completely insane.
nvim has a lot of "fun" plugins that you wouldn't actually use so I think you might have ran into that.
i can tell you dont actually SSH often by tbe way. Also, tmux doesnt magically reduce resource requirements of your applications
You're right. I don't use SSH that often due to kubernetes, infact I only use ssh for connecting to my desktop to access my tmux sessions and it's great. I know where you're trying to go with this and it's simply not true.
Who said anything about tmux? We're talking about neovim which is extremely light weight and the LSP's don't sit around being active all the time. They have a set duration where they terminate when unused which is simply not possible in most IDE's (LSP based ones are OK, but have problems reconnecting).
and kernel panics are exceedingly rare on windows. i havent BSOD'd in eons
I haven't had a kernel panic once on reliable hardware. Linux is way more stable than windows device drivers and progressively less reliable graphics drivers.
This isn't right. It was certainly true in the nineties, but I haven't seen one in years on Windows and I spend many hours a day in it both for work and play.
It just feels like it's hard to nail down your preferred workflow / setup ... but it's likely worth it if you're using it daily!
Are there any good visual or video demos of using this type of setup? I'm having trouble picturing what makes people really love this type of TUI-only workflow.
Just use a fuzzy file finder within the terminal or within vim itself.
I typically have a terminal-heavy workflow so it's very rare that I'm browsing to files from within my desktop, but if I am using Dolphin to look for a file I have a "Open terminal here" shortcut and then I'll usually just run "nvim doc.md".
Why not give it a try? You'll likely find that there's an adjustment period and you can always switch back to your old editor if you don't like it. The beauty of it is that you can build it into whatever IDE you want instead of having useless features shoved into your IDE whether you use them or not.
This kind of setup is at its most powerful when you live on the command line though. For instance, you need to modify .py files across multiple projects that mention a certain variable, have a certain word in their name, and were modified within the last month.
That search is a bit easier in bash/zsh than it is in most IDEs and the strength of vim/neovim is the shell integration.
The nice thing is that I rely only on the keyboard, no need to point with the mouse. It may not be faster, but typing is sequential and there’s no context switching. So muscle memory helps a lot. Just like you don’t think about each character when you write, I don’t really think about the shortcuts and commands I use.
Another thing I picked up from my time with emacs was making keybinds to interact with the "other" window. One macro I use often will delete the second line of the file in my current window, save, change to the other window, delete second line, save, change back to original window. When activated from keybind it all happens approximately instantly. I also have some binds to jump to the top of the other window's file (without leaving my cursor stuck over there) and so on, letting me keep my cursor in the main area most of the time.
Also the buffer’s local variable in vim comes from different sources. In emacs, a lot of stuff are tied to a major or minor mode. You only have to toggle them to switch between keybinds, syntax,…
There's a hackish way to do it by watching for Neovim command line commands that start with "/Users/" (change it if you are on other OS).
Your coding agent can probably hack something up based on:
`//Hackish supports drag and drop files into Neovim by examining when command line starts with "/Users/".`
My setup looks something like this:
|ai |nvim |git view |
|___| |________ |
|ai | |terminal |
| |(proj selector)| |
for AI I found oh-my-pi from can1357 it's magical how good it is. It was a top rated post on HN awhile back.
However, I do still run visual studio in parallel for debugging. It's basically essential when dealing with console game development.
Almost all such complaints are close to “I want to be cool and be seen as an haxor, but all I know is a bit of VSCode and IDEA, make it easier for me, plz”.
However, Neovim explicitely states that they don't want to turn VIM into an IDE. The feature parent is talking about seem to be falling into that type of vertical integration instead of composability.
Unfortunately I don’t remember what episode it was or even if it was specifically on an episode of The Standup, or if it was some other video that he and ThePrimagen did outside of The Standup.
Original HN post here if you’re interested. https://news.ycombinator.com/item?id=7279358
I've always wondered what this legend is doing now
I don't think comparison to other editors is a good basis for deciding what should be pulled in. The vi ecosystem was and remains weird to those outside, but in a way that is internally consistent to the usage patterns of its own user over decades.
Also, percentage of users using X feature is also a bad selection criteria for pulling a plugin provided feature, unless that number is 100% and there is little deviation in configuring it. There is very little friction in pulling in a plugin as a user.
So what are some good criteria for absorbing plugin functionality?
- extensions that provide an API for entire ecosystems (plenary, lazy.nvim)
- plugins that add missing features or concepts that are to useful, and timeless to ignore
- plugins that would benefit themselves or neovim by moving to native code
Honestly, the bar for absorbing plugins should be pretty high. There should be a real benefit that outweighs the cost of more maintenance, coupling, and ultimately cost.
The cost of installing plugins is pretty low, and they are great at keeping the core software simple.
Prior to 0.9 (if I recall correctly), you had to install a plugin to be able to interface with LSP servers, and in 0.9 they integrated the support into NeoVim itself.
The entire software development world would be much simpler if nobody needs new features, bugs and CVEs don't exist, or "just pin the version" works.
> "can't do things since there are no plugins yet"
Depending on what I am doing, I will probably go back to VSCode to get things done. Terminal editors are nice, but VSCode's extension ecosystem and usability is unmatched. I speak of that as someone who has spent hundreds of hours developing VSCode extensions. For me, "can't do things" is not (necessarily) a reason to set up Neovim plugins. It means I should figure out 1) if that's something I need to do regularly 2) If so, what's the best way to get it done.
(I am very well aware of what you can do with vim/Neovim plugins, just like zsh and tmux etc. Not spending time hand writing my config or setting up my plugins is an intentional choice. I like to start with a commonly used setup, discover pain points and bottlenecks, and then optimize or find some other solutions.)
Your arguments here are valid, for a particular kind of person who values a particular kind of workflow.
Some of us would rather use vi than vscode. If you take away the plugin ecosystem, the core value is still there.
So not the red-herringly 10 min (and there are hundreds of keybinds, so the initial learning wasn't 10 min either)
> like to start with a commonly used setup, discover pain points and bottlenecks, and then optimize or find some other solutions.)
Which you've presumably already done at least twice with vim and VSCode, so again it's just a waste of time to start from scratch yet again instead of configuring for the things you know you need
For some, this stage of a project attracts tinkerers and builders, and lets the community shape how things are done in the future. It's not always practical, but it does have a certain appeal.
> 0.13 “The year of Batteries Included”
> 0.12 “The year of Nvim OOTB”
At this point I just want a decent Helix-Evil-Mode.
I will have to try it out once it lands in neovim just to see if I can wrap my muscle memory around it.
Ctrl+v, 8, j, shift+i, add the text, Esc.
Which works if you need to edit several aligned lines in a row. The one thing I'm missing is putting the cursors on the next found position of a search term which would make it much more useful.
It's entirely possible that you don't need multiple cursors
If those places can be created automatically then again it's just a macro you execute over many lines.
Multi cursor is the feature that increased my productivity the most across the board.
Especially as code is formal notation, such that it’s structured quite rigidly, macros composition can be seen as a meta language. Multi cursors is more suited for the “work hard, not smart”, like preferring litteral search instead of learning regex.
(Just like searching with / replaced 98% of my navigation)
Editing something without having to actually place the cursor anywhere is a killer feature
Also neovim can show you your substitutions live, no need for a plugin anymore. It's the default.
Since VS Code is already an inefficient way to move around a code base, I don't think we should take any lessons seriously outside of how useful the LSP protocol become for adoption.
P.S.: multi-cursor is not about moving around the code base and therefore not taking lessons about navigation has no impact in this matter.
2) Regex is great, and vim is a good place to exercise the “try a regex” reflex. And on the regular old bash command line, it is great for making stuff like locate more precise.
That said, I do find myself using recursive macros quite often. They're an easy way to make a set of random little changes which would be hard to put into a solid regex. Especially when filtering and formatting logs to produce a list of error messages on a condensed format for review. It doesn't happen as often, but I also find them incredible when doing more complex substitution across a project.
Otherwise, as a sibling comment said, incremental search/replace is your friend.
So you either cycle through cursors (if your editor has a concept of "primary cursor") to see before/after or you do it blindly and accept a chance to be wrong
Much more powerful than "change all my selections to the next input" IMO.
You search for OLD, replace it with NWE, then notice the typo, delete 2 chars and type EW. How can search and replace help you here without searching for NWE anew?
Yeah, do try it out to at least see the difference
How does multiple cursors work anyway? How do you place them? By search? Is it used for anything other than working on matching text?
And it's also used for new text entry, not just editing matching text, e.g., add an extra field to each of these 5 arrays
Oh neat!
Here’s a video example [2]:
[1]: https://neovim.io/doc/user/usr_10/#_visual-block-mode
[2]: https://www.reddit.com/r/vim/comments/jai57c/the_usefulness_...
What sold me was not even the editor itself at first, it was the workflow. I can leave sessions running, bounce between projects instantly, and my system still feels light. That matters a lot once you get used to having multiple things going at the same time.
Claude Code also helps a lot with the rough edges. When I run into some niche config issue or weird tooling problem, it is usually fixable in minutes instead of turning into a rabbit hole.
Most of the previous features are replicable with new code, except for incremental selection. treesitter-modules[1] serves as a good bridge between old and new APIs.
[1] https://github.com/MeanderingProgrammer/treesitter-modules.n...
Note that this might conflict with some text-object plugins, such as mini.ai, which define an/in by default.
Just kidding, that will never happen.
This isn't a problem, really, for non interactive commands, but causes issues with interactive ones. I personally prefer vim's approach, though not enough to abandon neovim.
My initial issue: https://github.com/neovim/neovim/issues/35258 The interactive issue: https://github.com/neovim/neovim/issues/1496
I really just want a, do the old thing setting. It was simpler and worked better.
[0] https://gist.github.com/Konfekt/8e484af2955a0c7bfe82114df683...
Can someone try to sell me this over lazy.nvim? I asked Claude to convert lazy config to pack and I was not happy with it because how verbose it turned out
https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
Verbose? The new plugin manager's interface is literature just vim.pack.add({url}), not sure what is verbose about that
You may argue that you don't need lazy loading, which is fine, but they're not 1-to-1 compatible.
[1]: https://github.com/neovim/neovim/issues/35562#issuecomment-3...
But as indicated by my comment in the specific case for lazy loading, the plugin manager is the wrong place to have it. Regarding its other features I am not sure most of them need to be part of the plugin manager either (at least from the "plugin spec" part) and are better suited as extensions to other parts of core neovim (e.g. options for plugins might need better `vim.{o,g}` support for nested objects, unsure). Maybe specifying nested dependencies might make sense to add to `vim.pack`.
All this to say: yea, now it is more verbose, but it doesn't have to be.
https://learnvimscriptthehardway.stevelosh.com/chapters/53.h...
They do; I used minpac [1] back in the day with Vim. And now Neovim has vim.pack.
Every so often, a movement to create Vim and Neovim configurations with zero (or minimal) 3rd party plugins becomes popular. This means no lazyvim as the package manager.
The lazyvim package manager has all the bells and whistles, especially lazy loading plugins, which reduces Neovim's startup time if you have dozens of plugins installed. My LazyVim [2] configuration has 35 plugins total but only 6 load at startup; startup time: 76ms. Plugins you don't use often aren't loaded unless necessary.
Either opencode, claude, gemini, copilot, basically most that are relevant :D
Its a pretty light connection-layer, so it helps with sending context.
:term claude
In a split goes a long way for me!
vaf (visual around function) <space>ad (leader key add docstring).
And it documents the functions with my system prompt instructions for what good docstings should look like.
Pressing C-z on neovim puts me back in the terminal so I can do whatever I need to do and when that is done I just type 'fg' in the terminal and it opens up my neovim again, exactly as it was.
On Neovim, very exciting and interesting to see 0.12.0. It'll be interesting to see if folks really do migrating and at what speed to the new built-in plugin system. There's still dozens of other still used plugin systems, but LazyVim seems to have really cemented itself as the lead (and is used in AstroNvim). It feels like vim-pack is trying to be lighter still. Will it work? Will it get adopted? Will be neat to see. PR for vim-pack: https://github.com/neovim/neovim/pull/34009
Last, I still dream of a day where neovim headless is capable of running multiple different clients at once. The rpc architecture is so powerful and so amazing. But we're still (afaik) anchored to having once canonical screen, where-as I want to be able to have multiple editors, looking at different views of the workspace, with different layouts, and specialty windows like IDE debuggers in their own layouts. It's hard to dream of neovim disaggregating itself, blowing up the screen.c, but maybe maybe maybe maybe some decade, possibly, I hope.
I'm kind of desperate to switch. Getting massive FOMO from colleagues using VS Code. But I really like using the keyboard to navigate. What should I do?
Does NeoVim support Claude Code?
For doing something quick, VS Code's Vim mode is… fine. But not if you're something serious. I often quit it in disgust and go back to Neovim.
Lua has been a big boon to advanced configuration and the plugin ecosystem and Neovim supports everything I'd want and more. LSP and treesitter for instance are still better handled by Neovim.
If you dislike Lua (I'm not a fan) I recommend Fennel, but either way it's much better than Vimscript.
As for Claude there are at least two Neovim plugins for it. I use one of them and it works well but I can't remember which.
[1]: https://www.lazyvim.org/ [2]: https://youtu.be/N93cTbtLCIM
Course and book (free html, available pdf and dead tree). Covers everything I've needed concisely.
Are there specific features you’re missing from vscode?
:term claude
It will also expand special characters so you can do something like
:term claude “refactor %”
And Claude starts work on your current file right away. Also your buffers will update with Claude’s edits!
One major difference is neovim allowing to use Lua for configuration and plugins. I find Lua to be neater than vimscript.
Why does it need to? Just open CC in another terminal window or tab. Or run it in a split inside vim, using `:term`.
Although no LLM support in the editor, I personally just run Claude Code in a separate terminal, but if you want AI in the editor you'll have to look elsewhere.
I did try Neovim with Copilot a while back, and Google shows a few NeoVim Claude Code plugins, so it's probable that if you want an LLM in your text editor, NeoVim might work :)
I’m still not clear on what Mason is doing in my config after the switch but oh well.
https://github.com/neovim/nvim-lspconfig#important-%EF%B8%8F
and in a pinned issue.
and nvim-lspconfig :help has a migration guide:
https://github.com/neovim/nvim-lspconfig/blob/16812abf0e8d81...
Mason was always just a package manager for LSP servers. It used to be you needed the nvim-lspconfig plugin to properly configure LSP servers to work with neovim; to help with that there was the mason-lspconfig plugin that basically mapped LSP servers (as installed by mason) to nvim-lspconfig LSP configurations to make it all Just Work.
Now nvim-lspconfig and mason-lspconfig are no longer required thanks to the `vim.lsp.config`/`vim.lsp.enable` setup so you don't need them unless you want the little bit of automagic setup. Mason you can retain if you find it easier to install LSP servers through it, otherwise you can drop that too. Personally I manage my LSP tooling through distro/mise and replaced the lspconfig plugins with just a few autocommands and manually grabbing the config files from nvim-lspconfig git repo as needed.
vim.lsp.config(<lsp server>, config)
just return the config as a table i.e
vim.lsp.config("emmet_ls", { filetypes = { "html", "css", "sass", "scss", "less", "svelte", "gotmpl", }, })
will become
return { filetypes = { "html", "css", "sass", "scss", "less", "svelte", "gotmpl", }, }
in lsp/emmet_ls.lua - file name is very important btw
Update: after updating everything the errors have disappeared, phew.
I proxy to neovim instances for each level. Still working out some kinks but soon to complete it
!make !ps aux Etc.
The new ! just isn't as useful, and it's harder to get back to see the outputs. The old ! Was just a drop in way quickly do something like ctrl-z command fg.
[0] https://gist.github.com/Konfekt/8e484af2955a0c7bfe82114df683...
Until something comparable for Neovim comes out, I just don't see how I can switch back. I would happily pay for this. I'm sure there are a lot of people in the same boat as me.
The vast vast majority of my code is written by Claude Code, so I don’t write much. But when I do it’s like an exercise in warding off programming atrophy
However, if you were entertaining the idea of slowly switching to Zig, the build system would be the place to start. Moving away from CMake is worth it even if you don't push it further.
But yeah, the C-Zig interop story is so good it's a no brainer if you want to "modernize" your C codebase, and you can do so incrementally instead of stopping the world for a rewrite.
why "slow" just re-write it with ai. and to be clear im 0% joking and am prepared to be downvoted by people who haven't yet understood how feasible this kind of thing already is and how utterly trivial it will be in the near future
Sadly, this is the general trend with neovim in general: less focus on stability, more and more focus on shiny new things. If I didn't have an nvim config that I'm used to I would have switched to plain vim ages ago.
But the UI is also an interface, and the user is part of the total system. That system interface is broken if you change default mappings.
It doesn't matter if the interfacing component is software or a user.
The Neovim developers have been extremely clear that part of the process of getting to 1.0 is finalising the API, and that there will be breaking changes en-route.
To be clear, it's fine to have breaking changes. Especially if you're working towards something substantial.
But nvim and its plugin ecosystem seem to be altogether too keen to change absolutely everything and adopt all bleeding edge developments. Even when a mature system would serve the purpose just as well.
Any rewrite is massive friction, I’m sure probably meant port? The only annoyance with Rust ports is if you have to support varargs. Hopefully that will come to an end soon.
I'm hitting the limit due to a system that uses lists of nested rules or decision trees.
https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
I'd guess if you don't care about lazy loading and OK with just loading everything all the time - vim.pack is great to have as a built-in.
That being said, there is a way to lazy-load the plugins — Evgeni has a guide for that [1]. The "Load not during startup" variant is really simple with putting `vim.pack.add()` into `vim.schedule()`. The other myriad of options (keys, cmds, event) that lazy.nvim provides would require you to set up appropriate autocommands.
It gives me vibes of writing in Go. Everything is right there — builtin — but there's some verbosity to bear with.
[1]: https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
``` vim.api.nvim_create_autocmd("User", ... ```
But it only solves the actual lazy part. Not sure how you can solve defining plugin dependency graph for such loading that lazy.nvim allows.
I can try experimenting with it anyway.
This is actually super interesting, but then I realized it can't be true. :)