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.

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

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.

Whats with all the fuss over multicursor. How is this different from just using '.'

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.

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.

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.

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

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

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

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/

AFAIK it's mostly about stabilizing the RPC API and Lua stdlib:

https://github.com/neovim/neovim/issues/20451

Maybe when `:!` works the way vi does and POSIX says it must.

Just kidding, that will never happen.

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.