fzf is a fantastic utility, written by an author with a history of writing useful things. He's also a vim user, and in addition to his other vim plugins he has created an "enhancement" plugin called fzf.vim.
One of the neat things
fzf.vim does is make it easy to create new commands
for fuzzy searches. If you're like me, you probably have some absurd number of project
repositories you keep around and jump to, as necessary. Not everything is in
the same directory (e.g.
~/work/), naturally, and with a laptop, desktop,
and a couple other machines the less-frequently used repos may be where one
least expects them to be — or not present at all.
It's not hugely annoying, just a sort of mild pain to have to spend several
extra seconds doing a fuzzy search manually, rather than having
fzf do it.
But we do have
fzf, and it's not difficult at all to build out a new search,
so there's really no reason to keep on inflicting that pain.
Let's create a new command in my vimrc,
:Projects, that invokes
fzf to search through all the different work
directories I have.
What does this do?
Defines a new vim command,
No surprises here.
fzf#run() to run a
fzf#run() handle the actual execution and presentation of
fzf, as well
has dispatching the results back to the
fzf#wrap() is neat. It allows a command to take advantage of
option handling -- or not, by simply omitting it.
find to look for repositories
We know roughly where to look(
~/.vim/plugged) and how deep to
look. Just about everything I do is backed by git, so we can look for
repositories and return the parent of the found
.git back to
Note that the
find invocation deliberately omits a
-type d argument. I
do use git workdirs, meaning
.git may well be a file (a "gitlink").
Calls out to
rsrchboy#fzf#FindOrOpenTab() with the project selected
sink option tells
fzf#run() what to do with the results. In our
case we have provided
fzf#run() with a callback function, but you can also
use built-ins as sinks.
In general, I use one tab per project (repository) in vim. For me, this is a
nice balance of utility and sanity. It also allows me to do things like set
t:git_workdir to the git and workdir, respectively, of the
repository associated with the tab.
Our callback function first attempts to find an open tab with the workdir
requested; if found, it just switches to it and returns. (It should probably
admonish me to read the tab line before invoking
If not found. the callback function invokes
fzf#run() again. This time we
git ls-files to generate the source list for
fzf, allowing us to pick
a file to be opened by the given
Easier than writing this post, I'd say ;)
...um, kinda. I'm switching over from wordpress to Statocles, and porting my older posts over.
Still, who can resist "first post!" ;)
Google DNS is being hardcoded into a significant number of devices now. Which is nice, because it pretty much always works.
...except when you're trying to use Netflix and you have a tunnelbroker IPv6 tunnel. Ugh.
So, this is a brief followup to Stupid OpenWRT tricks. Or maybe "Getting Netflix to work when your ISP doesn't support IPv6 yet" is a better way to put it...
So, if you're like me you find yourself wondering why your broadband provider has a /32 IPv6 prefix assigned, and yet chooses not to use it, forcing one to either be IPv4-only (how 20'th century) or use an IPv6-over-IPv4 tunnel solution.
Fortunately there is a simple and free solution out there, courtesy of Hurricane Electric's rather fabulous tunnelbroker service. Obtaining an IPv6 prefix and setting up the tunnel is covered, extensively, so I won't go into it. It's also rather easy to set the tunnel up on an OpenWRT based router, like mine. The default setup is rather nice, but there are some changes you can make to your router configuration that will make it even nicer.
One of the most dangerous books I've ever even partially read is MJD's Higher Order Perl. In particular, its description of subroutine currying -- that is, building more specific functions out of more general purpose ones -- is a pattern I find incredibly useful.
The other day I found myself writing a number of routines that were surprisingly similar... kinda. They all implemented a common pattern, but across routines that were rather... different. I found myself wistfully longing for the familiar pattern of currying, and then realized -- I'm working in PERL, DAMNIT.
This is part of recent work of
Test::Moose::More to use subtests where they make sense. Here I was able to
curry one function --
_validate_subtest_wrapper() -- by passing it a
reference to another function, that it then invokes.
Excellent. Life is easier, as it should be.