51–60 of 93 posts
Earlier quoted context omitted.
Try installing it from the source into eg. ~/.fzf and run ~/.fzf/install (if I remember correctly). It will offer to add bindings for ctrl-r etc. to the shell's rc file. Easy to update, just run git pull in ~/.fzf and install again.
I'll give that a shot. Thank you.
https://github.com/peteryates/dotfiles/blob/master/zsh/.zshr...
If you still don't know how useful fzf is, you should start with integrating fzf and ctrl+r (reverse search).
How do you do this, by the way? I used sudo apt install fzf and then realized I still have to set up the ctrl-r part. I think I installed it differently on other systems previously, and those installs took care of the integration for me.
Am I the only one who prefers FZY ? https://github.com/jhawthorn/fzy
Another wonderful tool is "entr". It just runs a program when files change. It's incredible. I use it 20-40 times an hour to do very fast Dev/DevOps development: - "run Pytest when Python files change" - "I forgot how to use ps, run my-ps.sh when it changes and show me the output" - "rebuild all these Kubernetes resources when I edit the YAML files" - "run fast lint, then unit test Python files, then invoke one and s…
This will run a binary when any file on the directory tree changes:
#!/usr/bin/env sh
set -e
while true; do
inotifywait -e modify,create,delete,move -r $1 $2
done
If someone thinks this is magic or wizardy, instead of teaching them that fire exists (entr), teach them how to make fire first (inotify, linux inodes, etc.). Knowing what kind of events inodes support and how to do something when they happen is pretty powerful.
If you then want to use "entr" or similar instead of just calling inotifywait yourself, that's fair game. But TBH I have a hard time justifying a C or Rust program that's not going to be available / installed everywhere when a 3 LOC POSIX shell script can solve the same problem (and many many more).
I can totally see why fzf is a great utility and is indeed very cool but I don't see real value other than as a Vim plugin for Ctrl-P. For a Ctrl-R replacement in the terminal, it never sticked with me, because getting more than 1 results was distracting. Also, if I'm in a directory and want to open a file in vim that I'm not sure of its location, I do `vim` and then Ctrl-P. I tried to incorporate it a few times in m…
It can be useful to let you (fuzzily) pick from a list of things to execute a command. I use it to interact with git, i.e.: - checkout local git branch from curated list of branches fed through fzf - cherry pick commits from the previous (@{-1}) branch, using fzf + preview showing each commit's "diff" - pick recent SHA to git revert - pick files changed from {master,main,blead} - pick files currently uncommitted
I still need to find a satisfactory way to do “find in files” with vim. I use a custom script to call ag and it’s enough, but a bit clunky at times.
It has replaced vim’s “open file” and “switch to buffer” for me. I occasionally use it in the command line, by expanding *. Not that often as in Vim, but very useful. I still need to find a satisfactory way to do “find in files” with vim. I use a custom script to call ag and it’s enough, but a bit clunky at times.
I imagine you have a similar approach, what's clunky about it for you?
It has replaced vim’s “open file” and “switch to buffer” for me. I occasionally use it in the command line, by expanding *. Not that often as in Vim, but very useful. I still need to find a satisfactory way to do “find in files” with vim. I use a custom script to call ag and it’s enough, but a bit clunky at times.