Another usecase is tracking hours with Clockify. I was frustrated opening up the web everytime, so I wrote a script using fzf, httpie and jq. Love it now. [1]
That's a great idea, thanks. Do you know how to get it to show the preview window with the script value? Sometimes I need to explore which script task I need based on what it does
It uses jq's to_entries to pull out the script/command key pairs and then just cuts out the script name after you choose the command (assumes the command name doesn't have spaces).
plocate is a very fast mlocate alternative that uses indexes over trigrams and io_uring for reading the database. With fzf you can have a pretty fast fuzzy search over your entire indexed disk.
I'm the author of plocate. io_uring is not the primary part of the difference; it makes for a pretty good win if you have rotating disks (especially when you have many matches to test), but on SSD, it's pretty much inconsequential. The biggest difference really comes from the use of an index, as opposed to matching every single candidate against the pattern.
# https://github.com/junegunn/fzf/wiki/Examples#integration-with-z
# like normal z when used with arguments but displays an fzf prompt when used without.
unalias z 2> /dev/null
z() {
[ $# -gt 0 ] && _z "$*" && return
cd "$(_z -l 2>&1 | fzf --height 40% --nth 2.. --reverse --inline-info +s --tac --query "${*##-* }" | sed 's/^[0-9,.]* *//')"
}
This thing is magical! I use it as a quick scientific paper finder.
Basically have a folder with, probably thousands by now, papers (each file's name contains paper title, authors, year, journal) and by typing a couple words can fuzzy search for stuff by whatever fields.
It also works incredibly nicely with vim as a fuzzy search for either files or phrases within files.
A nice, I do the same but I convert all books, papers and powerpoints to pdf files with a rondom name or i use a hash of the content as name. Then in use ripgrepall with fzf to search for the information i'm looking for.
I haven't had the chance to test this, but this add-on promises to be able to pipe _any_ tab-completion suggestions from your shell into fzf, which to me sounds like the pinnacle of fzf awesomeness.
There's also skim[1], which would be a Rust fzy alternative.
But neither fzy nor skim quite do what fzf does, which is offer an simple feature-filled experience out of the box. The big draw is fzf Just Works™. I don't mind that it feels bloated and slow sometimes, because I don't want to spend a week figuring out how to make the other two do what fzf does without configuration or drama, and all the speed improvements in the world doesn't really matter when the bottleneck is the meatball behind the keyboard.
But does it really? Can one not simply not use the features one doesn't need?
Also, I fully appreciate not rewriting things that are C and already working just because -- but surely if something is already written in a safer language then C isn't really a step forward either.
fzf never struck me as the slightest bit slow. What am I doing wrong? You can configure it with an external previewer that can of cause be arbitrarily slow or bloated but you can hardly fault fzf for that.
In my experience fzf actually feels faster simply because it’s able to begin populating the output list before it finishes reading the input list. This means you get selection options immediately, whereas with fzy there can be a delay. This is particularly noticeable when working with large inputs (e.g. anything in the Linux kernel)
The real advantage of fzy over fzf is that fzy is actually better at guessing what you want (the documentation claims it's also faster but I never noticed a difference).
That fzy also forces you to think about good input providers (like fd instead of find) is just following the Unix philosophy of one tool doing what it's best at.
