Also in most use cases, clicking for each multicursor is the wrong way to do it.
With multicursor you can:
- Press a shortcut to auto select every instance of the characters that you already have highlighted (which is just s/foo/bar/g with visual feedback before confirming)
- Press your "select next occurrence" shortcut a few times so you're only changing the first few occurrences that you care about.
- Press your "select next occurrence" shortcut to select the instances you want and press your "skip next occurrence" shortcut to skip the instances you want to keep. That way you can change a bunch of "foo"s to "bar"s while keeping all "food"s as "food"s but also keeping those few instances of "foo" that you want to stay as "foo" (such as in comments, imports, tests, etc...)
- Press your "select next occurrence" shortcut (usually ctrl/cmd + d) each time if you literally want to see each instance before moving on to the next. Usually this is when you really want to make sure of something next to one of the occurrences.
- And finally clicking each cursor if there really is no simple pre-existing pattern for where you're trying to make changes
Sure, and if that’s the case you write a better pattern. The replacement s/foo/bar/g applies only to the current line as written. It’s easy to see if it will work or not. But if you also have food on the same line, you can write s/foo\ze\W/bar/g to match foo followed by a non-letter and replace only foo.
> Also in most use cases, clicking for each multicursor is the wrong way to do it.
Maybe, but I’ve sure spent a lot of time pair programming with people who do it, which is why I bring it up. For what it’s worth, I prefer multicursors, and my find-and-replace workflow is much as you describe, albeit entirely keyboard and regex driven. Your average junior programmer who just learned vscode three or four years ago only knows multiclicking though, and I don’t want to kill the momentum by interrupting to point out how they could use their tools better.
Suppose I'm editing a text file, and I'm working through a tradeoff between data volume and accuracy, where more accuracy requires more data. I have an array of 14 sensors, and I can configure them to take either 100-byte samples or 500-byte samples, and I can take samples at intervals between 1 and 60 seconds.
So I make myself a little table:
sensors size interval
14 100 1
14 100 30
14 100 60
Then I duplicate it: sensors size interval
14 100 1
14 100 30
14 100 60
14 100 1
14 100 30
14 100 60
I'm using kakoune, so I can put my cursor on the 100 in the first
duplicate row, press C twice, then press r5, and now I have this table: sensors size interval
14 100 1
14 100 30
14 100 60
14 500 1
14 500 30
14 500 60
Now, I want to know bytes per day, and this is where the math comes in.
I start adding columns. First I duplicate the three existing columns,
since I want to see them next to the result. I can do this by putting
a cursor at the beginning of each row, highlighting the whole thing,
and pasting. I also hit & to line up the pasted selections. sensors size interval
14 100 1 14 100 1
14 100 30 14 100 30
14 100 60 14 100 60
14 500 1 14 500 1
14 500 30 14 500 30
14 500 60 14 500 60
Now, because I don't want to have to think about the stack too hard,
I put 1440 (minutes per day) and 60 (seconds per minute) in before
the interval column. sensors size interval
14 100 1 14 100 1440 60 1
14 100 30 14 100 1440 60 30
14 100 60 14 100 1440 60 60
14 500 1 14 500 1440 60 1
14 500 30 14 500 1440 60 30
14 500 60 14 500 1440 60 60
Then I add my operations. And keep in mind I'm still using multiple
cursors, so all this stuff is just getting typed one time. sensors size interval
14 100 1 14 100 * 1440 * 60 * 1 / p
14 100 30 14 100 * 1440 * 60 * 30 / p
14 100 60 14 100 * 1440 * 60 * 60 / p
14 500 1 14 500 * 1440 * 60 * 1 / p
14 500 30 14 500 * 1440 * 60 * 30 / p
14 500 60 14 500 * 1440 * 60 * 60 / p
Now each line has a little dc program on it, like 14 500 * 1440 *
60 * 60 / p.I then highlight the back half of each row (again, still working with the same set of cursors the whole time, it takes way longer to explain this than it does to actually do it.) I type
| dc
and each of my selections gets run through dc. The result is: sensors size interval
14 100 1 120960000
14 100 30 4032000
14 100 60 2016000
14 500 1 604800000
14 500 30 20160000
14 500 60 10080000
That's not super readable, so I cursor over three times (multiselection
is still active!) and insert commas, and then I do it again: sensors size interval
14 100 1 120,960,000
14 100 30 4,032,000
14 100 60 2,016,000
14 500 1 604,800,000
14 500 30 20,160,000
14 500 60 10,080,000
The result is I've done a quick back-of-the-envelope calculation on
how much data I need to handle in each scenario.1. I wrote this comment using kakoune as the editor under w3m
2. I don’t know emacs as well as I’d like to. Anyone want to chime in on how you’d do this in emacs?