3 ms·
Macros live in a different (albeit adjacent) space to multiple cursors. When you record a macro, you need to be careful to encode commands that will work well
by barrkel 9y ago
Macros live in a different (albeit adjacent) space to multiple cursors.
When you record a macro, you need to be careful to encode commands that will work well wherever you apply it. That means skipping forward by a word rather than a fixed number of characters, sometimes doing fiddly operations around word and whitespace boundaries to make sure the cursor is in the expected position for the next step. When multiple cursors are used to emulate macros, you get a wysiwyg experience, rather than "programming" the cursor and finding out later during playback that it did the wrong thing.
Multiple cursors are also used as a replacement for text search and replace; sometimes the operation could be performed using a symbolic rename, sometimes it could be done by search and replace with live preview, but not when you want to skip some instances.
Probably 95% of my personal use of multiple cursors is for local refactoring, e.g. switching out a hash for an object or vice versa, where I want to change 'foo.bar' to 'foo[:bar]', but sometimes (electively) 'foo.fetch(:bar)'. Multiple cursors let me do both the selection and the editing in a wysiwyg fashion, where neither macros (typically with a 'find next' operation recorded last) nor a complex search and replace with capture group and interactive replacement are nearly as pleasant.
FWIW, for many years I used Borland IDEs and almost the only tool available for complex manipulation was keyboard macro record and playback (I spent probably 15 years only using keyboard macros). These days, though, the combination of synchronous editing (iedit mode in emacs) and multiple cursors have almost completely replaced my macro usage with much more usability due to the live feedback.
- carussell 9y ago> Multiple cursors are also used as a replacement for text search and replace; sometimes the operation could be performed using a symbolic rename, sometimes it could be done by search and replace with live preview, but not when you want to skip some instances. The Medium article about multiple cursors was from a Vim-centric perspective (in contrast to the linked article here, which was Emacs-focused). And in Vim, you'd do this with `n` and `.`. For example, `n.n.nn.` means, "change the second occurrence, too, and the third, but not the fourth, and do replace the fifth". Multiple cursors is no faster, and since you mentioned the benefit of not needing to carefully plan ahead (which I also think is important[1), I'll leave you with the observation that multiple cursors requires more planning than `.`. With `.`, the following thought process is valid: "Let's change this. Oh! And do these other ones, too." Compare to multiple cursors, where you have to don't have to plan as carefully as a recorded macro, but you still have to do some planning, because you have to start out knowing that you're going to change multiple things and then marking them before you make any change. So the spectrum looks like: # Recorded macros—requires lots of careful planning # Multiple cursors—requires little planning # Replay (`.`)—requires no planning at all; can fit your stream of consciousness 1. https://news.ycombinator.com/item?id=13350487 https://news.ycombinator.com/item?id=13350487
- sullyj3 9y agoThat's true if your edit is a single vim command, but if you're executing a few different ones at each location, . will only repeat the last. Hm, it strikes me that it might be a cool feature to interactively select as many of the last few commands you gave as you like, and copy them to a macro register. It seems like it wouldn't be too hard to implement, seeing as the commands you make are already stored in the undo tree.