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.

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.

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.

1) is there a reason both of the other responses to your comment are all full of Bro’s? It this an in-joke?

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.

Bro, not every guy/girl is a regex master, multi-cursor is a much better UI/UX wysiwyg editor for everyday users.

Terminal editors are not WSIWYG applications. I don't think multi-cursor is the correct for a vim motion workflow but I'll admit my vim-fu is not as strong but I get by with the substitute command + grep good enough where I rarely feel the need for a GUI editor to use multi-cursor.

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.

I think multi-cursors can be seen as an extension of macros, just that instead of defining the macro and navigating to the relevant places you instead navigate first and then execute the commands interactively (in essence skipping the part where you have to record). As a side effect you also don't need to be that concerned about what to do after having made a mistake. I've had some pretty nasty string-wrangling with the substitute command that could've been avoided by just using a macro and the other way around. I'd argue these things complement each other and there is no need to restrict yourself arbitrarily. Having it and not using it is better than needing and not having. I can recall countless times where multi-cursor would've been just the sweet-spot I needed.

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.

Sis, substitutions started being useful being I even learned Regex and I have done an incredible amount of edits with the just the bare minimum of Regex knowledge

Word Bro! Regex is so simple to read and easy to get right... and its like if Immanuel Kant wrote find and replace, yeah, learn a new language to do a single function... yEAH! 98% Bro! I'd marry Regex if I could (but if we got divorced it would be my exregex [which is almost a palindrome!] Bro!)

Regex search and replace is definitely among my most used features and the preview in NeoVim is amazing

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.

Without meaning to sound like the “friendship ended” meme, I was a heavy user of macros in vim and neovim. It was probably my favourite feature. After I switched to Helix, I began using multiple cursors and now those are my favourite feature, I barely use macros anymore. Being able to see your movements live and intelligently using multiple clipboard is not just powerful, it’s fun too and rewards well-designed code.

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

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

Highlighted search/replace does this pretty well too.

Not really, it only does it for the first edit, while multiple cursors offer continuous feedback for all further besides, search/replace has extra toolbar and usually can't as easily select, for example, "current Identifier under cursor" if those are different, so it's worse before the first edit as well

I'll have to try that out sometime. Never used multiple cursors. However, search/replace with vim/neovim isn't just the first edit either. It highlights all matches and shows you the proposed changes as you type as well. (It is probably a configurable thing).

How can it show proposed changes if search doesn't match anymore after edits?

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

I am not saying it's better or you shouldn't use multiple cursors. It does help a lot as opposed to the old way of not seeing what would have been changed.

How does multiple cursors work anyway? How do you place them? By search? Is it used for anything other than working on matching text?

Your place them via search, manual click, extending up/down the line, via "match current word"

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

I can picture it better now. Thanks.

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)

How do you place the cursors then?

In vim?

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.

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.

Not sure I under the Zed argument, VSCode has supported milti-cursors since the very beginning. It was made popular (not invented) by Sublime Text because it made it reaaaally easy (middle click+drag), so Atom and VSCode carried the feature.

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?

At least in e.g. Emacs and sublime text, you can mark all occurrences throughout the entire file. Assuming the matches are similar enough that the same motions apply even if you can't see the cursor, you can perform those operations.

Otherwise, as a sibling comment said, incremental search/replace is your friend.

You do a search/replace which has a similar function, although applied differently.

That's one challenge I haven't seen editors tackle correctly by, e.g. having some special condensed view where only lined with cursors are shown so you can see more cursors on the screen and easier scroll around to see even more skipping the rest of the text (like some git diff tools do, showing only diffs with minimal context)

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

This strikes me as a good idea I've never seen articulated before. Something like a sticky scroll which accrues all off screen cursors, limited to some max to prevent things getting out of hand.

The dot command, as you probably well know, is a macro that captures the last change: was it '3cw' or 'cE' or '7s' or <visual>s or 'ct)', all changed to the last insert. All intuitively without you even having to think about it.

Much more powerful than "change all my selections to the next input" IMO.

Lookup helix tutorial. It’s pretty useful.

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.

"Image API: vim.ui.img"

Oh neat!

one cursor for you one cursor for claude code :)

LLMs: Look, I can write code! neovim users: hold my beer, multicursor is here!

Looking forward to multiple cursors… but Vim/Neovim can already do some of the common use-cases for multiple cursors, like prepending (or appending) text to a bunch of lines using visual block mode [1].

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

Yes, and I use those. But it would be nice if it could be generalized to cases where the places that need to be edited didn't line up nicely in a block.

Agreed.

Any chance regular vim will some day get multiple cursors? That's the one thing I miss.

Helix editor is based around that. Better than vim default imo