Suggestion: override cfdo with cdo using a gate?
chiefjester opened this issue ยท 3 comments
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:
- If the user edits the
quicklist
,:Acks
will default to:cdo
under the hood. - Or there can be another mapping
:Ackr/:Acksc/:Ackc
? Which maps withcdo
. - ability to override
Acks
with:cdo
. - 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?)
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.
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.)
Sweet! Thank you @wincent This is indeed a very welcome change, thank you for bringing this to master. ๐๐ปโโ๏ธ