[Feature request] invoke `ag` interactively

[lotabout]

• Category
  • fzf binary
• OS
  • Linux
• Shell
  • bash

I've used fzf and fzf.vim and they are great! Ag command in fzf.vim will allows us to:

1. :Ag <pattern> will return the search result and pipe it to fzf
2. fzf will allows us to narrow down the above result to get what we want.

However, in ag's case, more often, we may want to change the <pattern> dynamically instead of changing the query to narrow down the result of a specific <pattern>. I'll give an image as example of this:

skim is a rust version of fzf, which provides an "interactive" mode to dynamically invoke the commands.

I understand the role of fzf is a general purpose "filter", and the above feature may be far from what fzf tries to be. Though as an end-user, I'd really like fzf to have this feature. Please consider about it, thanks!

[junegunn]

I don't have enough time these days, so I can't make any promises, but I'll think about it.

Anyway, here are some concerns that come to my mind.

• Rebuilding the input list from scratch can feel clunky. The list will be cleared, cursor will always be brought down to the bottom of the screen, tab-selected entries will be lost. And depending on the command used, there can be noticeable initial delay which will make the user wait until the first entry from the new command pops up.
• So restarting ag command every time you press a key can be an overkill, especially when the selectivity of the initial query is good. Isn't it silly to restart ag command when there are only a handful of matches?. It may suffice to rebuild the list only when some key is pressed such as CTRL-R (r for refresh). Like, you press that key only when there are too many matches and fzf filtering can't keep up. Note that it is possible to implement the idea externally using --expect and --print-query options, though it requires closing the current fzf window and opening a new one. So the experience will not be as nice, but in that way, we can keep the simplicity of fzf.
• Search syntax of fzf is not compatible with the regex used by ag command. Passing fzf query directly to ag command may or may not make sense. Such as !test 'run. Also fzf takes fuzzy terms but ag does not.

[junegunn]

Since I don't have answers to the above questions, I'll close the issue for now.

Actually, it's a bit hard for me to see the point of the example. If we restart ag on every change of the query string, fzf no longer works as a filter, but simply becomes a selector interface for external process, which is not the problem fzf was designed to solve. It would make more sense if we restart the ag process not on every update of query, but on an explicit request. But in that case, we can already implement the feature using --expect as I mentioned above.

[andreyorst]

fzf no longer works as a filter, but simply becomes a selector interface for external process, which is not the problem fzf was designed to solve.

We could use fzf to as a selector interface until we're satisfied with provided list, and then fix this list and use fzf as a filler again. In my opinion this is more reliable then restarting fzf every time you realized that your ag query isn't what you want.

[mateuszr]

I think it would be good to look back into this feature request. There are cases when having possibility to actually rerun a command makes more sense, e.g. when initial amount of lines is really big. For instance when using some full text search engine instead of grep. I found some workarounds to for such case, but they are making it more cumbersome. Instead, taking inspiration from skim would be an interesting option.
I've created a PR to give this idea a try. Here's some initial observations:

Rebuilding the input list from scratch can feel clunky.

It seems that the performance is pretty good on Linux and Mac.

So restarting ag command every time you press a key can be an overkill

In certain situations yes, but then it should be noted that "interactive mode" is better suited in cases when we could actually benefit from having a subset of results already provided by a command itself. E.g. when initial result set is huge.

Search syntax of fzf is not compatible with the regex used by ag command.

Definitely yes. It's hard to imagine that other commands would have the same syntax for filtering. In this case "interactive mode" shouldn't assume the "extended-search mode" and pass everything as-is or maybe it should implement a key binding for switching off interactive mode and then filtering based on fzf syntax. I think skim does that.