-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
support for re-executing a command on input #965
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It appears I'm not alone: https://www.reddit.com/r/vim/comments/4kjeur/live_searching_in_vim/ The wiki suggests something like this: But, to be clear, that essentially just What I'm looking for is a way to treat the currently entered text as a proper regex to hand of to e.g. |
You can see the previous discussion on the matter here: #751. There are questions and concerns that haven't been addressed, and I still don't think I want to add the exact feature to fzf, well at least for now. As you mentioned above, it's clear that this is not the type of problem fzf was initially designed to solve. It's introducing another mode of execution; fzf no longer acts as a filter, filtering is completely performed by some external program, and this mode will not work with STDIN. What I'm mainly concerned is that adding this new mode may hurt the simplicity of the project. Maybe there are programs that are better suited, particularly designed for this use case? Or you can just take a look at the project mentioned in the previous issue. I'm actually quite content with the current workflow, using ag as the primary filter, and fzf as the secondary. Most of the time I know what I'm looking for, so I have no problem coming up with the base query for ag, and even if I don't, "catting" every file and feeding the lines into fzf works quite well for small to mid-sized projects that have less than a few million lines in total. And though it's not exactly what you want but fzf provides Having said that, it's not that I'm totally against the idea, I just don't find myself needing it so it's not my priority. And I'd like to think about it really hard and go over pros and cons of all the options before rushing into an implementation. There might be better ways to integrate the feature without sacrificing the conceptual simplicity of fzf. Will revisit this later, but I'm going to close it for now. Thanks for the suggestion. |
# Reload input list with different sources seq 10 | fzf --bind 'ctrl-a:reload(seq 100),ctrl-b:reload(seq 1000)' # Reload as you type seq 10 | fzf --bind 'change:reload:seq {q}' --phony # Integration with ripgrep RG_PREFIX="rg --column --line-number --no-heading --color=always --smart-case " INITIAL_QUERY="" FZF_DEFAULT_COMMAND="$RG_PREFIX '$INITIAL_QUERY'" \ fzf --bind "change:reload:$RG_PREFIX {q} || true" \ --ansi --phony --query "$INITIAL_QUERY" Close #751 Close #965 Close #974 Close #1736 Related #1723
I would like to use
fzf
to interactively rungrep
(orag
/ack
/etc), where typing would causegrep
to be re-executed as necessary. Ideally, there would be a configurable debounce setting, so quickly typing text doesn't trigger the command excessively. In case visuals help, this is basically the use case I have in mind (from syohex/emacs-helm-ag):In this case,
fzf
would be less of a fuzzy finder, and more of a generic selection interface.Is this a feature that would be accepted? If so, I might find time to work on it.
The text was updated successfully, but these errors were encountered: