Over the last fourteen years of using vim, the rate at which I discover features and commands probably slowed a lot after the first six to eight years. As knowledge of awesomeness expanded, and business reasons limit my lurking in #vim irc, the the intake has been kinda slow. It didn’t really take long to learn enough vi to be highly editing effective, and some years of using vim all the fricken time, will probably teach anyone most of the important stuff.
Today, I discovered a new-old thing. Or had one of those “Where have you been all my life?” moments.
I often find myself copying a path; usually done via tmux’s copy/paste features, as I’m a keyboard whore, and not every terminal I rely on lets you use a mouse so readily for that. And then pasting it into a vim command to open a file, be it :e[dit], :tabe[dit], :sp[lit], or :vsp[lit], or even just to go do `vim somefile’.
Today, I was doing a fair bit of find commands to go look up a file, because when you have a solid state drive and some people like dozens of folders in nesting, sometimes that’s faster than remembering enough for tab completion.
Then I had a thought, “Hey, isn’t there a :find for looking up files? There’s gotta be a way to open those results in a buffer.” And of course there is!
Much to my disappointment, :find foo doesn’t really search many places. The default path on *nix is something like ., /usr/include, and the heck a trailing coma means (path=.,/usr/include,,). Which is great for something like :find sysexits.h but not so much for crawling a directory structure. But there’s a solution!
-> suddenly qux/ham/spam/eggs/and/yippee/ki/yay/foo opens in the current buffer.
There’s a fair number of vim things that I’ve learned over the years, and don’t often need. On an occasion they teach me good things when I am smart enough to go look for them again.