[dandotway]

> In reality, you would think about and act upon each in turn

Here's a real example from real coding I was doing, then:

  color.r = 42;
  color.g = 42;
  color.b = 42;

I want to bump the 'r' and 'b' from 42 up to 255 but leave 'g' alone. So I,

  1. Alt-click after the two 42's I want to change
  2. Ctrl-Backspace, type '255'
  3. Done

With a vim I could

  1. Use '/42<RET>' or '?42<RET>' to search towards a 42 I want to change
  2. Use 'n' or 'N' command to skip the 42 I don't want to change (possibly)
  3. Use 'cw' followed by '255<ESC>' to change the first 42
  4. Use 'n' or 'N' to get to the next 42, skipping the 42 I don't want to change
  5. Use '.' to repeat the 'cw255<ESC>'

Alternatively with vim

  1. Use ':%s/= 42/= 255/gc' to query replace the right occurrences
  2. Answer 'y' or 'n' for each occurrence
  3. Still requires more keystrokes, time, and thought than VSCodium

It's funny all these posts presuming that multi-cursor is a gimmick only used by idiots who don't know how to use regular expression query replace and the vim '.' command. Yeah, I know how to use those, and multi-cursor is often faster. And VSCodium has a powerful multi-file query-replace that is faster to learn than the equivalent vim/emacs/grep/sed.

[gsinclair]

Yep, sure, and if that kind of code change was a frequent experience then I can imagine myself thinking multi-cursors would pay their way. As it is, I’d be perfectly happy using hjkl (because the change sites are so close) and cw and . and not for a second thinking my editing experience was suffering.

However, your comments will cause me to take a good look now at VSCodium and https://github.com/mg979/vim-visual-multi