Skip to content
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

Add an option to select instantly when the search only finds one answer #2494

Closed
10 tasks done
lamdevhs opened this issue May 19, 2021 · 3 comments
Closed
10 tasks done

Comments

@lamdevhs
Copy link

lamdevhs commented May 19, 2021

  • I have read through the manual page (man fzf)
  • I have the latest version of fzf
  • I have searched through the existing issues

Info

  • OS
    • Linux
    • Mac OS X
    • Windows
    • Etc.
  • Shell
    • bash
    • zsh
    • fish

Problem / Steps to reproduce

Hello, I wanted to ask if it were possible to add an option to enable the following behavior: when typing in the query field, if fzf encounters only one result (the filter returns only one entry), it gets selected immediately, and fzf exits, without needing the user to hit 'enter' to validate the selection. Dmenu for example has that option, in the shape of a patch, called 'instant' https://tools.suckless.org/dmenu/patches/instant/

To be clear this is different from the behavior of --select1, which solely checks if the input is comprised of a single entry/item. Here, even if the input were to be many items, when the user searches through those items, if the search results become depleted to the point when there is only one result left, that result would be immediately accepted and fzf would quit.

Originally when reading the man page, I actually thought that --select1 did what I am proposing it. I was overjoyed till I tested it and it ended up not working at all like I expected. On that front I feel like perhaps the man page should be reworded: "Automatically select the only match" to me sounds closer to the behavior I'm talking about here, though it depends on what the definition of 'match' is. Perhaps "Automatically select the only input item" might be more explicit, or something similar?

In some sense this option I'm proposing kind of subsumes --select1, I think, but also allows the behavior of 'automated acceptance' to be triggered during a search/filtering made by the user, and not just at the launch of the program.

I might consider trying to code that behavior myself and then ask for a pull, if you are not against the feature as an idea/concept but you would deem it low priority on the realization level.

@junegunn
Copy link
Owner

Looks like the documentation has room for improvement. Let me explain.

"Automatically select the only match"

--select-1 was designed to be used with --query (#27, #36) in the scripting context. If an initial --query is given, it behaves as such (when you don't pass a --query, that is same as passing an empty query (--query "") which matches all items in the list, so the statement is still valid). We added the option not to start the UI in shell scripts, which would cause a quick flickering of the screen, when there's no need. Once the UI starts, the option is discarded. I put the option under "Scripting" section of the man page, but I guess that is not clear enough.

--select-1 in interactive context was suggested in the past (see #459) but I rejected the idea because I think it doesn't go well with the idea of "fuzzy matching".

If you're looking for a terminal version of dmenu, you might want to take a look at https://github.com/p-gen/smenu. It may be a better choice than fzf for simple menus.

@pestala
Copy link

pestala commented Oct 19, 2021

I know you've thought this through carefully, but would like to share a different perspective (and hopefully convince you to at least reconsider):

  1. fzf does have a "-e" option, which tells fzf to find an exact match. We are also able to use anchors to limit the search. I believe both of these are contrary to fuzzy search, but are very useful. The --query="SEARCH_TERM" -1 combo is superfluous since grep can do the same thing 10 times faster, just without the fuzzy part and the chances of hitting a single match on a large file with fuzzy search and having the result be useful must be pretty low.
  2. Lately, I have been using fzf for my script menus, and it has been able to do nearly everything I had previously needed to script manually. Having to script for this specific use case (exit on single match) creates some disparity in the interface (using fzf for one menu and pure bash for another), which requires jumping through hoops to get pure bash to match fzf's interface. Or I can opt not to do that but have a mismatched interface.
  3. There are workflows where a single match and exit makes sense. As an example, I have a number of details I need to include in emails to my clients: email addresses to all parties, subject line, body, and any file attachments. Each subject will require a different body and different file. I have scripted a loop that presents the different items that I need for the email, and I use bash read -n 1 to allow a single character to be input and an action to be taken immediately. While setting up the email, I have my browser open on one screen and this script running on the other. I bounce between these screens quickly, hitting a single character with my left hand to select the next item for the email in the bash script and using my right hand to quickly move the mouse to the next area of the email in the browser. Using fzf, it requires a minimum of two keystrokes in interactive mode to get the same result, since selecting requires hitting enter. This also requires moving my right hand from the mouse to hit enter and moving it back to the mouse. This is slower and more prone to keystroke errors (i.e. accidentally hitting a key adjacent to the enter key).
  4. Under the one-keystroke method in this use case, if the user mistakenly hits the wrong key, it doesn't do any harm; the user can just hit the right key if needed.
  5. You've had several other users ask for this feature, and there are probably an infinite number of scenarios where this functionality would be useful for your various users.
  6. As far as I can tell, no other program that I have found (smenu, bash select; do; ...; done, and a number of obscure projects) has this functionality, so it always has to be scripted manually.

If you've read this far, thank you for your time! :)

@pestala
Copy link

pestala commented Oct 22, 2021

If anyone is interested in this functionality, I'm using the following as a workaround (in bash):

a=$(fzf -e --bind "change:accept" --print-query < FILE | head -1)
grep "$a" FILE

junegunn added a commit that referenced this issue Apr 1, 2023
Close #2629
Close #2494
Close #459
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants