Narrow down the candidates by multiple keywords

[mykola-hrebenyuk]

It would be very handy if fzf could perform keywords matching separated by a space " ".

For example, if we look for match of candidates that meet both conditions "foo" and "bar":

foo bar

You can also specify negative conditions with an exclamation mark "!". This matches candidates that meet "foo" but do not meet "bar":

foo !bar

[junegunn]

Hi, thanks for the suggestion.

It surely is a nice-to-have feature, but I usually take the minimalist approach and do not try to add a feature which is not necessary in order to keep the implementation simple.

1. We can just write foobar or barfoo. Of course it does not match foo-bar and bar-foo at the same time, or foboar, but I personally haven't felt the need for being able to do so especially when working with a list of files. So I'm not sure. Can you give me an example where this feature would be a great benefit?
2. The user will not be able to match literal space character, so we should introduce a command-line option to enable or disable this feature. Alternatively, maybe we could allow user to split the query with TAB key or something.
3. Regarding !, I'm reluctant to introduce a custom syntax which can add complexity. I want fzf to be instantly obvious to anyone so that it does not need any more explanation. Also, as the case of space, the user will not be able to match ! character in this case.
4. FYI, fzf caches the intermediate results to speed up the search and improve the user experience. (e.g. appl -> apple, or pple -> apple, etc.) The code is going to be much more complex if we allow multiple matchers. So I'm a bit worried about that.

So the answer is not yes or no at this point. I'll think about it. Thanks.

[mykola-hrebenyuk]

Thanks for your explanations.

Actually the idea was borrowed from extensively using of zaw with extended-search enabled.
If you are interested you can read about it by clicking on the link above and scrolling to the bottom of page.

Anyway, thanks for great command line booster!

[junegunn]

zaw looks interesting, thanks for the link!

I'm currently trying out zaw. One thing I noticed is that it does not support fuzzy-matching (I can't type in ape to find apple), and it seems to me that one of the benefits of its extended-search mode is that it can be used to complement this limitation (ap e will match apple).

Having an advanced, extended search mode on fzf would be nice, but because of the inherent difference between fzf and zaw, we may have to come up an implementation that better suits fzf, rather than just following the way of zaw.

[mykola-hrebenyuk]

I'm currently trying out zaw.

You may take a look on zaw in action from this blog entry.

One thing I noticed is that it does not support fuzzy-matching

Yes, it filters entries in its own way by tokens provided on its prompt. And it is very handy indeed.
For example, if you look for xml file but you are not sure what exactly one, you can just start from:

xml$

After that entries would be filtered to match only xml files. At this point you recalled that it has "party" in its path/name so you type:

par

As entries are further narrowing down on your screen, you would see from the result that the file is actually related to identity provider configuration, thus you type:

idp

Finally the whole query would look xml$ par idp for getting

.../.../.../idp-shibboleth/.../.../relaying-parties.xml

In other words your filter query develops with developing (clerifying) your thoughts in your head. In this approach order of query keywords doesn't matter, whereas in fuzzy-matcher it does. (You can't just type xmlparidp and get the same result).

I believe it would be great to have this power by providing 'keywords' mode to fzf.
Let give end user right to choose what better suits its workflow.

[junegunn]

Thanks for the detailed explanation. The usage pattern you mentioned makes perfect sense.
At the same time, it highlights the contrast between the keyword mode and the current behavior of fzf
and leaves me with some questions.

• Should fzf try to replace zaw? Why not use both? (Of course one can't use zaw if not on zsh though.)
• Does it make sense to have a non-fuzzy-finding method in fzf which stands for "fuzzy finder"?
• If we've decided to implement one, why should we support only ^ and $, instead of full regular expression? Wouldn't it be better to be able to write something like (ya?ml|xml)$ [0-9]+?

I don't have answers to these questions yet.
Maybe I need more time (or more experience with the tool) to be able to evaluate the options.

[mykola-hrebenyuk]

Should fzf try to replace zaw? Why not use both? (Of course one can't use zaw if not on zsh though.)

Zaw's killer feature -- matching by multiple keywords without order --- was main reason for me switching to zsh.
Though I personally using it only as better alternative for incremental history search and that's speed up my work enormously. Having the feature in fzf would mean free of choice to use it: no matter whatever a shell you use and a workflow you are stick with, you always have 'universal filter tool' -- fzf -- that suits your particular needs.

Does it make sense to have a non-fuzzy-finding method in fzf which stands for "fuzzy finder"?

Don't see any problem with that. Of course it's up to you to take the final decision.

If we've decided to implement one, why should we support only ^ and $, instead of full regular expression? Wouldn't it be better to be able to write something like (ya?ml|xml)$ [0-9]+?

From my perspective full regex would be overhead. Because fzf is not sed. We run fzf to be more productive thus spend as less time on it as possible. And leave it as soon as our find query is matched.

[junegunn]

At this point, I think allowing out-of-order matching of patterns could be a nice add-on to fzf, but I'm not so sure about supporting ^ or $, since they invalidate the basic premise of fzf, fuzzy matching.

So for example, if we look for an item that includes apple, banana, and orange, but not sure about the ordering between them, we may type in something like aple ornge bnna, which is an OOO fuzzy matching. I'm not against having such feature, although increased complexity in implementation is still a concern.

[junegunn]

An idea:

• Treat tokens without ^ or $ as fuzzy matching patterns
• If a token starts with ^ or ends with $, it is matched as it is.

[mykola-hrebenyuk]

Or add option +t, --tokens that mimics zaw's search engine.

[junegunn]

Oh, I don't mean to make the scheme I mentioned above the default behavior of fzf, it will have to be explicitly enabled by the user with a command-line option. In my opinion, the proposed scheme is an improvement over zaw's method as it allows fuzzy matching.

[junegunn]

Check out https://github.com/junegunn/fzf#extended-search-mode

It's not exactly same as the extended-search mode of zaw, as it uses fuzzy matcher by default as mentioned in the previous comment, unless a word starts with a single quote. I haven't given enough thought about this new syntax so I'm not confident about it, but it looks okay to me at the moment. (FYI it was borrowed from the similar one from Clojure syntax)