[Discussion] Restarting source command

[junegunn]

#751 and #965 suggested a new mode of execution where fzf restarts the source command whenever the query string is changed. They specifically wanted this for using fzf with a primary search command such as grep, ag, or rg. Although I can see the appeal, there are obvious impedance mismatches.

• fzf no longer works as the primary filter. It simply becomes a selector interface whose only role is to constantly restart child processes with the input.
• fzf has its own search syntax, which is not compatible with the arguments for ag or rg.

And It's not just a simple option but a new, extra mode of execution that is not very "unix-y", and I'm concerned that it will hurt the conceptual simplicity of fzf.

A better idea I believe is to keep fzf simple and implement scripts using the existing options, and I think it's already possible to some level.

1. Refresh the source command when a special key is pressed. This can be easily implemented using --expect option.
2. Restart fzf and its source on every query change. This can be done using --bind change:accept, and some hacks. Little known and somewhat experimental --no-clear option can be used to reduce flickering of the screen, but unfortunately it doesn't work nicely with --height.

(code: https://gist.github.com/junegunn/4963bab6ace453f7f529d2d0e01b1d85)

I'd like to focus on non-disruptive, incremental changes we can make to help the development of such scripts. Polishing --no-clear comes to my mind first.

[thalesmello]

@junegunn Have you considered the possibility of binding a timeout after a certain length of time is passed, kind of like how CursorHold works in Vim?

Suppose something like:

fzf --expect=cursorhold --cursor-hold-timeout=500ms --require-input-before-cursor-hold ...

--expect=cursorhold would be triggered after a certain length of time passed.
--cursor-hold-timeout=500ms would specify that amount of time
--require-input-before-cursor-hold would assert the timeout would only happen after some key was pressed

With all of that, it would be possible to implement similar behavior to how interactive selectors work, while keeping fzf a simple filter tool.

Besides, it could also have other uses, such as allowing scripts with timeout "default" options to be built. Kind of like how multi-boot systems work. A screen that allows the user to interact and choose a option, but it he doesn't do anything, it will just pick the default option (note that, for this to work, the --require-input-before-cursor-hold wouldn't be used).

What do you think about that?