> "or you could just hit ^z and use the unparalleled power of the Unix shell."

Or I could use both, when the need arises, which frankly it never has for me. Ack.vim does not preclude using ^z when you have a special need, it optimizes the common case. And Ack.vim is much nicer than !ack <cword>

> "install ack.vim, slow down vim's startup and bloat your installation"

Well I don't run vim on a z80, so the difference would be pretty hard to measure ;). The way modern well-coded vim plugins like Ack.vim work involves lazyloading using 'autoload' (which is poorly named.) Ack.vim includes plugin/ack.vim (p/av) and autoload/ack.vim (a/av). p/av loads when you start vim, but is a light-weight file that only contains keybindings and settings variables. The actual code of Ack.vim, the function definitions, exists in a/av which is loaded lazily, when one of those functions is called by a keybinding created in p/av.

The result is a truly negligible startup impact.

https://github.com/mileszs/ack.vim/blob/master/plugin/ack.vi...

https://github.com/mileszs/ack.vim/blob/master/autoload/ack....

"simple things should be easy, hard things should be possible."

I rarely (if ever) need to make matches world readable from the context of text editing. When I do, there's nothing stopping me from using ^z, but until that day comes, a plug-in is going to be fewer keystrokes, faster, and better integrated with what I was already doing.

One thing I don't understand, is how do you handle mistakes with the 'unix-as-ide' approach? I was using sed to refactor. Now, I typically use bufdo %s/foo/bar/gc, because it's much more forgiving. It's the same story with a lot of stuff you can ctrl-z for - if you can do it inside vim, it's usually far easier to control and roll back.

Git helps you with those mistakes, otherwise, yes, very unforgiving