Closed ibhagwan closed 4 months ago
I see. --expect
was added before --bind
was even a thing, so its implementation currently does not consider bound actions on the same key, but it really should.
A few more thoughts:
accept
is implied in --expect
. So additional accept
shouldn't be necessary, but it shouldn't be an issue either.
fzf --multi --expect=ctrl-q --bind=ctrl-q:select-all
--bind
when --expect
was added. So now that we have --bind
, --expect
actually can be thought of an action that can be bound to a key. Some ideas.
--bind ctrl-q:select-all+accept-with-key
--bind ctrl-q:select-all+print(arbitrary string)+accept
Got it @junegunn.
I like your ideas as they give maximum flexibility, I also thought about a simpler solution, perhaps something like --print-accept-key
which adds the accept key to the output similarly to --print-query
?
Yeah, I also considered that approach, but I think consolidating the features around the event binding mechanism is the way to go.
6b4358f will make --expect
compatible with --bind
. Also, I'll also be adding print(...)
action.
Ty @junegunn!
Can confirm this works on the latest devel
commit 0.52.1 (6b4358f6)
.
Hi again @junegunn 👋
When scripting fzf, it is sometimes desirable to perform different actions upon completion depending on the key pressed, for example, in fzf-lua users use
enter
to open the file andctrl-q
to send the selection to quickfix list.Now say that instead of sending the selection to quick fix we want to send all results to quickfix, we can do that with
--bind=ctrl-q:select-all+accept
but the output doesn’t print the pressed keybind, for that we need to add--expect:ctrl-q
, however combining both we lose the--bind
as expect takes over: