Suggestion: override cfdo with cdo using a gate?

[chiefjester]

One workflow I got bitten is when I try to edit the quicklist and do an :Acks /foo/bar/ only to find my deleted entries replaced. :Acks is using :cfdo and operates per file. If the deleted entries file path still in the quicklist (there are entries you haven't deleted), it'll replace all occurrences still, which I find it counterintuitive.

While :cdo is generally slower than its :cfdo counterpart, if your workflow includes deleting entries in the quicklist, basically refining it via :Quacks and manual editing. Shouldn't it default to :cdo instead of :cfdo that way it'll respect the quicklist you edited?

Here are a couple of suggestions:

1. If the user edits the quicklist, :Acks will default to :cdo under the hood.
2. Or there can be another mapping :Ackr/:Acksc/:Ackc? Which maps with cdo.
3. ability to override Acks with :cdo.
4. Or replace :cfdo with :cdo since the results are the same. (If it's using async jobs, I don't think it's going be a problem if it's a tad slower?)

[wincent]

I believe this was discussed a bit a few years ago (in #23), but I can't remember whether Vim had :cdo back then (it definitely didn't have :cfdo at that point).

I agree that it can be a bit surprising to have :Acks operate on all the files in the quickfix listing, instead of just the lines visible in it. As with that other issue you opened (#61), this is probably one where we'd want an option that enabled people to keep the old behavior, but we'd default to the new behavior. It's possible that we might want another command, but I am inclined to not bother with it until somebody actually asks for it (and even then, I'd want a good name for it! 😂).

I'd be interested to see if :cdo is really that much slower in the real world. It might not even be noticeable unless you're dealing with dozens (or more) matches per file. It's probably reasonable to use :cfdo, like you say, when the user hasn't edited the quickfix listing.

To your other point, :Acks isn't async (:Ack etc are), and to be honest it never really occurred to me that it should be.

[wincent]

That's another one for the "next" branch. If it stands up to testing, we can merge it to "master". (Have only tested it in the most cursory fashion so far, but in an initial test it seemed fine.)

[chiefjester]

Sweet! Thank you @wincent This is indeed a very welcome change, thank you for bringing this to master. 🙇🏻‍♂️