I like fzf; but it’s in no way a Linux fuzzy finder tool. In fact the author describes it as “an interactive Unix filter”, and it runs perfectly happily on my FreeBSD system.
well, it is on a redhat blog after all… I use it on a mac too. Still I found the article pretty good. I did not know about this preview feature and I am totally going to use that all the time now.
So I’m not the only one who finds squeezing Linux where it should either be completely omitted, or Unix should be used, jarring - ip(8), systemd(1), sure… but fzf(1)?
What does this do? It binds ctrl-E to do four things:
Use fzf to find a filename to open, call it TARGET
Pretend like the user just typed “edit $TARGET” at a (fake) bash prompt
Insert this command into the bash history, so we can press the up-arrow to go back to it
Actually run the command “edit $TARGET”
Clear the command line in case there was text there when we pressed ctrl-E.
So in all ways I could think of, this makes “ctrl-E file.txt” equivalent to manually typing in “edit file.txt” in whichever subfolder it is. In other words, this effectively gives Bash the “search and open file” functionality of an IDE. This alias alone probably saves me ten minutes or more over a workday.
Funny story! Why do I redefine the default fzf color theme at the bottom of the snippet? When typing, fzf by default marks matching snippets in yellow-green color. In the dark-mode color scheme of my terminal, this means the fzf search dialog looks like bright white text that has yellow-greenish splotches rapidly spreading over it. Seeing this literally makes my eyes hurt. It took me a while to figure out why: white light that turns yellow is the visual representation of my retina taking damage from staring at a too-strong light source. The retina does not have pain receptors, so the brain emulates the necessary pain signal of looking at the sun by detecting this situation from visual cues. What cues? White spots that turn greenish yellow…
I really enjoyed this article. At the risk of sounding like a rewrite-it-in-Rust fanboy, I have replaced FZF with Skim and found it to be a very positive experience. It’s a pretty-good replacement for most things.
If I’m understanding, you want the “mod” part of the query string to be restricted to the first matching path segment rather than matching across “monsters/dungeon”? That does sound useful.
Thinking about a possible implementation it doesn’t actually sound too hard to add to my fuzzy finder zf, and would fit well with the overall goals too
If you can provide that feature, you’d have gained yourself a new user (and possibly contributor). Ping me if you add that. You could even point me to the source code files where such a change would be made, and I might take a crack at it myself.
But, yes, I want to be able to segment the matching, because my primary use for fuzzy finding is fuzzy file (path) finding. I already know roughly the dir tree of my projects in my head, so I want to be able to get at files quickly.
Thanks for making an issue, I’ll keep you updated! I have a release I’m wrapping up to bring things up to date with Zig 0.10.0, but after that I think I’ll give this a shot.
The main goal of zf was to make it really easy to find the correct file using only the basename. But in the cases where you have a lot of files with the same name, I think this path segment idea of yours would be a great addition.
for what it’s worth, when working with ansible, I always need matching on the path since the base names for many files in a typical ansible setup is main.yml
I like fzf; but it’s in no way a Linux fuzzy finder tool. In fact the author describes it as “an interactive Unix filter”, and it runs perfectly happily on my FreeBSD system.
well, it is on a redhat blog after all… I use it on a mac too. Still I found the article pretty good. I did not know about this preview feature and I am totally going to use that all the time now.
I’ve used it on windows too!
So I’m not the only one who finds squeezing Linux where it should either be completely omitted, or Unix should be used, jarring -
ip(8),systemd(1), sure… butfzf(1)?Let me take this tangentially related opportunity to share my fzf bashrc entry: https://gist.github.com/FeepingCreature/6ddaf8acacd690e1e97b25dca713b0f2
What does this do? It binds ctrl-E to do four things:
So in all ways I could think of, this makes “ctrl-E file.txt” equivalent to manually typing in “edit file.txt” in whichever subfolder it is. In other words, this effectively gives Bash the “search and open file” functionality of an IDE. This alias alone probably saves me ten minutes or more over a workday.
Funny story! Why do I redefine the default fzf color theme at the bottom of the snippet? When typing, fzf by default marks matching snippets in yellow-green color. In the dark-mode color scheme of my terminal, this means the fzf search dialog looks like bright white text that has yellow-greenish splotches rapidly spreading over it. Seeing this literally makes my eyes hurt. It took me a while to figure out why: white light that turns yellow is the visual representation of my retina taking damage from staring at a too-strong light source. The retina does not have pain receptors, so the brain emulates the necessary pain signal of looking at the sun by detecting this situation from visual cues. What cues? White spots that turn greenish yellow…
I have done something similar in https://github.com/mk12/fish-fzf. It binds Ctrl-O to open fzf, and:
This is insanely useful, thanks for sharing
I really enjoyed this article. At the risk of sounding like a rewrite-it-in-Rust fanboy, I have replaced FZF with Skim and found it to be a very positive experience. It’s a pretty-good replacement for most things.
I haven’t found a fuzzy finder which does this: Given the following lines:
If I type app/mod/fo/ba/baz, I want to filter down to app/models/foo/bar/baz.rb, and not include any of the others.
If I’m understanding, you want the “mod” part of the query string to be restricted to the first matching path segment rather than matching across “monsters/dungeon”? That does sound useful.
Thinking about a possible implementation it doesn’t actually sound too hard to add to my fuzzy finder zf, and would fit well with the overall goals too
If you can provide that feature, you’d have gained yourself a new user (and possibly contributor). Ping me if you add that. You could even point me to the source code files where such a change would be made, and I might take a crack at it myself.
But, yes, I want to be able to segment the matching, because my primary use for fuzzy finding is fuzzy file (path) finding. I already know roughly the dir tree of my projects in my head, so I want to be able to get at files quickly.
I made you a github issue to track this feature request: https://github.com/natecraddock/zf/issues/11
Thanks for making an issue, I’ll keep you updated! I have a release I’m wrapping up to bring things up to date with Zig 0.10.0, but after that I think I’ll give this a shot.
The main goal of zf was to make it really easy to find the correct file using only the basename. But in the cases where you have a lot of files with the same name, I think this path segment idea of yours would be a great addition.
for what it’s worth, when working with ansible, I always need matching on the path since the base names for many files in a typical ansible setup is
main.yml