It probably goes against Vim tradition, culture and freedom to choose, but I wish they added even more built-in features (like Helix) that are currently implemented in competing and sometimes brittle plugins and have to be put together into also competing vim starter packs and distros of plugins and config files just to have a modern setup out of the box.
I agree in principle that absorbing the best from the ecosystem is good. However, anything pulled into core should have a long lifetime and be considered part of the API. This deserves careful consideration, and plugins work really well until it is clear there is a reason to pull something in.
This is what happened with the Language Server Protocol.
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.
I believe neovim started as a fork specifically to implement features like LSP support and package management, VIM eventually also caught up. But i don't believe anything is out of the table, or against Vim tradition. Which features do you want to see built-in, specifically?
I’m also pretty sure that on an episode of The Standup, one of the Neovim core maintainers TJ DeVries (Teej) said that it is a good idea to prove new ideas in the form of a plugin rather than submitting pull requests for Neovim itself with new ideas that have not yet been tested out and proven in the real world. Implicitly implying that indeed Neovim is open to bring features from plugins into core Neovim itself, if they are proven to be useful for a lot of people.
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.
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”.
I think what they did with first-party support for LSP would be an example of this.
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.
Multi cursor support in VSCode replaced 98% of my need for macros. Yes, macros are more powerful, but they are pretty easy to get wrong. With multiple cursors, it's far easier to spot where your inputs don't work out and adjust accordingly.
Multi cursor is the feature that increased my productivity the most across the board.
Forget macros and multi-cursor. (Regex) substitutions from vim's command line replaced 98% of my editing needs and rendered a lot of my vim-fu useless.
(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.
Proper macros are vim and emacs one. They have proper movement shortcut that fits both code and prose.
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.
Kakoune has replaced many features with multicursor, including the sed-like commands (where you just select an area, search for patterns inside it to create the multiple cursors, then perform regular edits (which also means you can perform much more complex than simple replaces).
It is really useful for refactors, e.g. even if you don't have any LSP (e.g. for plain text) you can easily rename symbols, reorder/select in log files, etc
I'm not sure how people typically use neovim, but in Zed I find multiple cursors (especially combined with multiple file buffers) extremely ergonomic for refactoring quickly and easily where tools like find and replace or simple renaming doesn't suffice. It lets you scan through and add cursors where you need them, then perform your edits across locations and even files all at once. It's so nice that it played a significant role in me keeping Zed early on despite it missing a lot of extensions I used in VS Code.
I am so used to sed-style, regex powered find/replace, that this use admittedly never occured to me. As a result, multi-cursor seemed mostly useless outside of pair programming that I never do.
I will have to try it out once it lands in neovim just to see if I can wrap my muscle memory around it.
I've always told myself I should learn to do these sed/regex find and replace techniques, but my origins are not sophisticated and I use computers like that orangutan hammering nails in the video with David Attenborough https://youtu.be/IFACrIx5SZ0?si=NcWGBNq272KoYB2i&t=84
It's entirely possible that you don't need multiple cursors
For me the nice thing about multiple cursors is when it would take more time to write the regex than it does to just throw down say 8 cursors and update the spots.
There’s an overlap between “Find and Replace” and Macros, but it’s too small for multi cursors to be particularly useful for me. Especially with emacs where I can bring up all the lines in a separate buffer and edit them there (occur-mode) or do the same for a set of files (grep-mode and wgrep)
You have very convenient macros.
If there is something you want to do in places you are going to mark first then you can just execute it right there instead. If it's just one edit you just do it right there without macro and use the dot to repeat it in more places.
If those places can be created automatically then again it's just a macro you execute over many lines.
You'd do text editing with it with the coolest feedback loop - immediately seeing the changes and what those changes apply to beforehand, that's different from having to repeat some macro multiple times
Really excited about this! At least in Sublime Text I've found multiple cursors a really powerful tool for ad-hoc transformations on snippets of semi-structured text or instantly and visually applying the same edit on multiple similar lines.
dot repeat is the wrong comparison. A closer one would be macros, but even then a good multiple cursors implementation is often faster, more intuitive, and requires less cognitive overhead. One of the better examples of the usefulness of multiple cursors is from Emacs Rocks (link goes to 0:23):
Multiple cursors were the killer feature that got me to start using Sublime Text back in ~2010. Still an absolute staple of my text editing toolbox. Ctrl-D Ctrl-D Ctrl-D ...
It's funny because I miss this one all the time. I got use it in Sublime and VScode before making the jump to Neovim. I know you can get similar functionality from macros and what not, but it's just not the same.
Always interesting when a project stays 0 ver for so long- anyone close to the project know what would be considered significant enough for a "v1" release?
In Vim, :! cleans up the tty context and hands it off to the child program, to do whatever it wants, you can open any TUI program and it will work as expected.
In Neovim, :! just uses a plain pipe. Actually I believe GVim has the same problem. Since both Vim implementations now have a built in terminal handling stack anyway, I wonder if that could be used to unify the behavior.
Just nvim. Neovim runs :! commands non-interactively, capturing the output in a pipe. vim, on the other hand, suspends itself and runs the command in an external shell.
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.
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
I always thought Vim/Nvim already had a built-in package manager, git clone inside ~/.vim/pack/*/start, am I missing anything by not using a "real" package manager?
I imagine you are left with manual dependencies, manual updates, and possibly without lazy loading or portable configuration. That stuff is not strictly necessary and may be easy to roll your own if you're very into it, but it's comfortable to have a standard.
Yes tab split, neovim on the left, companion on the right, or different tabs. The plugin codecompanion.nvim is also great. I use it for common tasks. Like:
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.
Yeah working on a smart way to rate limit stale requests for those who don't have accounts.But the final version will allow anybody who is not a bot, to get into a vim instance without logging in. Thanks for the feedback.
I unintentionally ran the main branch when testing some changes and a lot of my config broke (mostly around LSPs, CodeCompanion was much slower streaming its responses) so might wait a bit before upgrading.
I'm using VIM - Vi IMproved 9.1. What am I missing?
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?
I've been using VIM/NVIM on and off for a while and the one thing that made it stick for me over VSCode was LazyVim [1]. If you're missing out on something IDE like VSCode, but you love vim it's a great way to go (it can take some getting used to so hang in there). EDIT LazyVim is based off nvim by the way. If your more into videos to learn about something this is a good intro to it from Elijah Manor [2]. I have my dotfiles stored on github that I use on my different machines, and use gnu `stow` and `make` to build them and that gives me my specific lazyvim setup free and quickly after just downloading a few dependencies.
Most of the active development in the ecosystem is done for neovim these days. If you're using barebones vim then yea you probably won't see much difference, otherwise you have no choice
If it's just using the keyboard that's holding you back from VSCode, you'll be pleased to know it has plenty of its own shortcuts, as well as a "VIM navigation" mode you can turn on.
I motivated my Cursor-colleagues to switch to tmux+nvim -- they don't use it all the time, but they enjoy the vibe. Claude is running on some tmux pans. Much nicer than VSCode!
Use the Neovim extension for VScode. It requires you to have Neovim installed, but it works way better then the Vim extension since it passes commands to neovim instead of using emulation.
What are you getting FOMO over? Been using Neovim since it forked from Vim and I'm very happy with it.
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.
the zig build system is the only thing that actually matters in these notes. nobody maintains a parallel build system for fun—it's a clear signal they're finally pathfinding a way to migrate the core away from legacy c. zig's native interop is basically the only way to do this incrementally without the massive friction of a full rust rewrite. definitely makes nvim feel like a much more serious environment for systems-level performance work.
It doesn't necessarily mean they're going to migrate from C, building a C project is just so much nicer with Zig than fiddling around with CMake. You got people using it as a build system even for Go projects, especially if they're relying on CGo.
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.
> the only way to do this incrementally without the massive friction of a full rust rewrite
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.
Couldn't disagree more. Why move away from solid, mature build systems to something relatively fringe like zig.
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.
I've been loving NeoVim with AstroNvim so much. I'd done some editor configuration and it felt daunting and mostly just... didn't. And I was not good about using the leader key, because of tmux to zellij problems, that nothing was discoverable (zellij adds visual overlays to guide you through usage, unlike tmux's memorize everything approach). AstroNvim has changed both of these so much for me: there's excellent community packs (https://github.com/AstroNvim/astrocommunity) that are easy to drop in that have good configuration out of the box for everything you could want to do, and the leader key has a wonderful little bottom-of-screen UI for itself that helps you discover what's available (that astronvim plugins naturally grow/augment).
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.
> The folke/lazy.nvim is the most used plugin manager at the time of this writing. And rightly so: it is very capable with lots of features. Ironically, this itself makes it not very suitable to be a part of Neovim as most of the features come with significant code and maintenance complexity. Plus the whole idea of treating lazy loading as the main goal of a plugin manager does not sit well with Neovim core team.
I'd stick to lazy.nvim for now. Lazy loading is really neat and lazy.nvim's ability to specify plugin dependencies isn't something vim.pack has either.
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.
82 comments:
It probably goes against Vim tradition, culture and freedom to choose, but I wish they added even more built-in features (like Helix) that are currently implemented in competing and sometimes brittle plugins and have to be put together into also competing vim starter packs and distros of plugins and config files just to have a modern setup out of the box.
I agree in principle that absorbing the best from the ecosystem is good. However, anything pulled into core should have a long lifetime and be considered part of the API. This deserves careful consideration, and plugins work really well until it is clear there is a reason to pull something in.
This is what happened with the Language Server Protocol.
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.
I believe neovim started as a fork specifically to implement features like LSP support and package management, VIM eventually also caught up. But i don't believe anything is out of the table, or against Vim tradition. Which features do you want to see built-in, specifically?
I’m also pretty sure that on an episode of The Standup, one of the Neovim core maintainers TJ DeVries (Teej) said that it is a good idea to prove new ideas in the form of a plugin rather than submitting pull requests for Neovim itself with new ideas that have not yet been tested out and proven in the real world. Implicitly implying that indeed Neovim is open to bring features from plugins into core Neovim itself, if they are proven to be useful for a lot of people.
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.
Neovim is actively moving in that direction.
Define “modern”!
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”.
I think what they did with first-party support for LSP would be an example of this.
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.
Up next for 0.13: multiple cursors! I have no idea what I'd do with this feature but it sounds intriguing.
https://neovim.io/roadmap/
Multi cursor support in VSCode replaced 98% of my need for macros. Yes, macros are more powerful, but they are pretty easy to get wrong. With multiple cursors, it's far easier to spot where your inputs don't work out and adjust accordingly.
Multi cursor is the feature that increased my productivity the most across the board.
Forget macros and multi-cursor. (Regex) substitutions from vim's command line replaced 98% of my editing needs and rendered a lot of my vim-fu useless.
(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.
Proper macros are vim and emacs one. They have proper movement shortcut that fits both code and prose.
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.
Kakoune has replaced many features with multicursor, including the sed-like commands (where you just select an area, search for patterns inside it to create the multiple cursors, then perform regular edits (which also means you can perform much more complex than simple replaces). It is really useful for refactors, e.g. even if you don't have any LSP (e.g. for plain text) you can easily rename symbols, reorder/select in log files, etc
I'm not sure how people typically use neovim, but in Zed I find multiple cursors (especially combined with multiple file buffers) extremely ergonomic for refactoring quickly and easily where tools like find and replace or simple renaming doesn't suffice. It lets you scan through and add cursors where you need them, then perform your edits across locations and even files all at once. It's so nice that it played a significant role in me keeping Zed early on despite it missing a lot of extensions I used in VS Code.
I am so used to sed-style, regex powered find/replace, that this use admittedly never occured to me. As a result, multi-cursor seemed mostly useless outside of pair programming that I never do.
I will have to try it out once it lands in neovim just to see if I can wrap my muscle memory around it.
I've always told myself I should learn to do these sed/regex find and replace techniques, but my origins are not sophisticated and I use computers like that orangutan hammering nails in the video with David Attenborough https://youtu.be/IFACrIx5SZ0?si=NcWGBNq272KoYB2i&t=84
It's entirely possible that you don't need multiple cursors
For me the nice thing about multiple cursors is when it would take more time to write the regex than it does to just throw down say 8 cursors and update the spots.
There’s an overlap between “Find and Replace” and Macros, but it’s too small for multi cursors to be particularly useful for me. Especially with emacs where I can bring up all the lines in a separate buffer and edit them there (occur-mode) or do the same for a set of files (grep-mode and wgrep)
You have very convenient macros. If there is something you want to do in places you are going to mark first then you can just execute it right there instead. If it's just one edit you just do it right there without macro and use the dot to repeat it in more places.
If those places can be created automatically then again it's just a macro you execute over many lines.
You'd do text editing with it with the coolest feedback loop - immediately seeing the changes and what those changes apply to beforehand, that's different from having to repeat some macro multiple times
"Image API: vim.ui.img"
Oh neat!
Really excited about this! At least in Sublime Text I've found multiple cursors a really powerful tool for ad-hoc transformations on snippets of semi-structured text or instantly and visually applying the same edit on multiple similar lines.
Whats with all the fuss over multicursor. How is this different from just using '.'
dot repeat is the wrong comparison. A closer one would be macros, but even then a good multiple cursors implementation is often faster, more intuitive, and requires less cognitive overhead. One of the better examples of the usefulness of multiple cursors is from Emacs Rocks (link goes to 0:23):
https://m.youtube.com/watch?v=jNa3axo40qM&t=23s
What do you when the things you want to change don't all fit on the screen at once?
one cursor for you one cursor for claude code :)
Multiple cursors were the killer feature that got me to start using Sublime Text back in ~2010. Still an absolute staple of my text editing toolbox. Ctrl-D Ctrl-D Ctrl-D ...
Lookup helix tutorial. It’s pretty useful.
It's funny because I miss this one all the time. I got use it in Sublime and VScode before making the jump to Neovim. I know you can get similar functionality from macros and what not, but it's just not the same.
The built-in incremental ast based visual selection is nice.
Always interesting when a project stays 0 ver for so long- anyone close to the project know what would be considered significant enough for a "v1" release?
There is a roadmap and github issue tracking what is needed for 1.0.
https://github.com/neovim/neovim/issues/20451
https://neovim.io/roadmap/
Possibly never: https://0ver.org/
Maybe when `:!` works the way vi does and POSIX says it must.
Just kidding, that will never happen.
What are referring to, out of interest? Does this apply just to nvim, or vim as well?
In Vim, :! cleans up the tty context and hands it off to the child program, to do whatever it wants, you can open any TUI program and it will work as expected. In Neovim, :! just uses a plain pipe. Actually I believe GVim has the same problem. Since both Vim implementations now have a built in terminal handling stack anyway, I wonder if that could be used to unify the behavior.
Just nvim. Neovim runs :! commands non-interactively, capturing the output in a pipe. vim, on the other hand, suspends itself and runs the command in an external shell.
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.
vi compatibility is explicitly a non-goal for neovim
https://neovim.io/charter/
AFAIK it's mostly about stabilizing the RPC API and Lua stdlib:
https://github.com/neovim/neovim/issues/20451
> - d21b8c949ad7 pack: add built-in plugin manager `vim.pack
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
Have a look here. This is incredible guide to the `vim.pack`.
https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
> how verbose it turned out
Verbose? The new plugin manager's interface is literature just vim.pack.add({url}), not sure what is verbose about that
If you want to replicate the lazy features then it will get verbose. Even using a dedicated plugin for lazy loading it's not as tight as lazy.nvim.
You may argue that you don't need lazy loading, which is fine, but they're not 1-to-1 compatible.
I'm assuming there will be something like lazy.nvim built on top of vim.pack. Some of the conventions might go away (ie constantly calling `.setup`).
I always thought Vim/Nvim already had a built-in package manager, git clone inside ~/.vim/pack/*/start, am I missing anything by not using a "real" package manager?
I imagine you are left with manual dependencies, manual updates, and possibly without lazy loading or portable configuration. That stuff is not strictly necessary and may be easy to roll your own if you're very into it, but it's comfortable to have a standard.
Not really. That’s what I do.
It being built in sounds nice, although I have some lines in my config that automatically install lazy if it’s missing.
Tried to switch but found lazy.nvim better
With all the supply chain attacks this last week, little hesitant to upgrade.
Is anyone using them vim with Claude or any of these coding tools? I want to, but I haven’t found a good workflow.
Sidekick.nvim is nice, you get a "real" terminal window on the side with many different agents to choose from.
Either opencode, claude, gemini, copilot, basically most that are relevant :D
Its a pretty light connection-layer, so it helps with sending context.
FWIW, it's also made by Folke, the same developer who made lazy.nvim and snacks.nvim, as well as some other high-quality plugins.
Yes tab split, neovim on the left, companion on the right, or different tabs. The plugin codecompanion.nvim is also great. I use it for common tasks. Like:
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.
Mentioned elsewhere, but
:term claude
In a split goes a long way for me!
If anybody wants to checkout my site to learn the basics of vim. Here it is:
https://vimgolf.ai
I proxy to neovim instances for each level. Still working out some kinks but soon to complete it
Seems like you need an account just to try it.
Yeah working on a smart way to rate limit stale requests for those who don't have accounts.But the final version will allow anybody who is not a bot, to get into a vim instance without logging in. Thanks for the feedback.
I unintentionally ran the main branch when testing some changes and a lot of my config broke (mostly around LSPs, CodeCompanion was much slower streaming its responses) so might wait a bit before upgrading.
Congrats on diff mode improvements. Hopefully forge style highlighting mode for two way diffs will be available next.
I'm using VIM - Vi IMproved 9.1. What am I missing?
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?
I've been using VIM/NVIM on and off for a while and the one thing that made it stick for me over VSCode was LazyVim [1]. If you're missing out on something IDE like VSCode, but you love vim it's a great way to go (it can take some getting used to so hang in there). EDIT LazyVim is based off nvim by the way. If your more into videos to learn about something this is a good intro to it from Elijah Manor [2]. I have my dotfiles stored on github that I use on my different machines, and use gnu `stow` and `make` to build them and that gives me my specific lazyvim setup free and quickly after just downloading a few dependencies.
[1]: https://www.lazyvim.org/ [2]: https://youtu.be/N93cTbtLCIM
To pile on to the LazyVim love, I recommend this site: https://lazyvim-ambitious-devs.phillips.codes/
Course and book (free html, available pdf and dead tree). Covers everything I've needed concisely.
Most of the active development in the ecosystem is done for neovim these days. If you're using barebones vim then yea you probably won't see much difference, otherwise you have no choice
Ymmv, but I have been very happy using classic vim’s “native claude support”
: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!
If it's just using the keyboard that's holding you back from VSCode, you'll be pleased to know it has plenty of its own shortcuts, as well as a "VIM navigation" mode you can turn on.
What do you use?
Resist hypes and just use whatever you feel like. Torvalds uses a 40 year old EMACS implementation and that seems to be working for him.
Used neovim and neovide for the last week (also had FOMO) and while they’re good (no major gripes) I ended up going back to macvim.
Are there specific features you’re missing from vscode?
I motivated my Cursor-colleagues to switch to tmux+nvim -- they don't use it all the time, but they enjoy the vibe. Claude is running on some tmux pans. Much nicer than VSCode!
What's the FOMO caused by? Asking as a vim user starting to get FOMOOFOMO.
You can use vim key binding in vs code.
Use the Neovim extension for VScode. It requires you to have Neovim installed, but it works way better then the Vim extension since it passes commands to neovim instead of using emulation.
What are you getting FOMO over? Been using Neovim since it forked from Vim and I'm very happy with it.
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.
the zig build system is the only thing that actually matters in these notes. nobody maintains a parallel build system for fun—it's a clear signal they're finally pathfinding a way to migrate the core away from legacy c. zig's native interop is basically the only way to do this incrementally without the massive friction of a full rust rewrite. definitely makes nvim feel like a much more serious environment for systems-level performance work.
It doesn't necessarily mean they're going to migrate from C, building a C project is just so much nicer with Zig than fiddling around with CMake. You got people using it as a build system even for Go projects, especially if they're relying on CGo.
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.
> the only way to do this incrementally without the massive friction of a full rust rewrite
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.
Couldn't disagree more. Why move away from solid, mature build systems to something relatively fringe like zig.
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.
I've been loving NeoVim with AstroNvim so much. I'd done some editor configuration and it felt daunting and mostly just... didn't. And I was not good about using the leader key, because of tmux to zellij problems, that nothing was discoverable (zellij adds visual overlays to guide you through usage, unlike tmux's memorize everything approach). AstroNvim has changed both of these so much for me: there's excellent community packs (https://github.com/AstroNvim/astrocommunity) that are easy to drop in that have good configuration out of the box for everything you could want to do, and the leader key has a wonderful little bottom-of-screen UI for itself that helps you discover what's available (that astronvim plugins naturally grow/augment).
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.
why put a built-in plugin manager. and if so why make it pack not lazy
> The folke/lazy.nvim is the most used plugin manager at the time of this writing. And rightly so: it is very capable with lots of features. Ironically, this itself makes it not very suitable to be a part of Neovim as most of the features come with significant code and maintenance complexity. Plus the whole idea of treating lazy loading as the main goal of a plugin manager does not sit well with Neovim core team.
https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
I'd stick to lazy.nvim for now. Lazy loading is really neat and lazy.nvim's ability to specify plugin dependencies isn't something vim.pack has either.
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.