junegunn / fzf

:cherry_blossom: A command-line fuzzy finder
https://junegunn.github.io/fzf/
MIT License
61.81k stars 2.35k forks source link

Replacing placeholder by the query when no match #3870

Closed jdujava closed 2 weeks ago

jdujava commented 2 weeks ago

Checklist

Output of fzf --version

0.53.0 (c4a9ccd6)

OS

Shell

Problem / Steps to reproduce

I would like to have a behavior similar to accept-or-print-query action, but for replacing the placeholder in the preview. This is easy enough to do, for example

[ -n {} ] && echo {} || echo {q}

fallbacks to the query when there is no match.

Since this seems to me to be common enough pattern ("choose from predefined set, or create custom entry"), it would be nice to have access to something like {?q}, which would expand to the current match, or to the query when there is no match.

junegunn commented 2 weeks ago

Thanks for the suggestion, but I don't think we need to implement it.

Since this seems to me to be common enough pattern ("choose from predefined set, or create custom entry")

I'm not sure about this. {q} and {} are inherently not interchangeable, because this is a fuzzy finder with its own search syntax. Let's take an example. Let's say you want to find a git add command for svg files, but not png files from your command history. It's natural to type gaddsvg !png in fzf. This is a perfectly fine search pattern, and in fact you're not encouraged to type the exact command with spaces like git add svg (see https://junegunn.github.io/fzf/search-syntax/#how-to-get-better-results). And you don't want to regard gaddsvg !png as a new command when there's no match.

Secondly, I'm not really a fan of shortcuts. They tend to make the program harder to understand in the long run, confuse users by giving them multiple ways to do the same thing. From a maintainer's point of view, a proliferation of shortcuts lead to a maintenance nightmare.

[ -n {} ] && echo {} || echo {q}

This is a nice, concise, and clear way of doing it.

jdujava commented 2 weeks ago

Of course, I agree that in general (as your example points out) it doesn't make sense to fallback from {} to {q}, but I had in mind something like choosing a word from the list of words/dictionary to get a translation, also allowing for typing a word not present in the list.

Secondly, I'm not really a fan of shortcuts. They tend to make the program harder to understand in the long run, confuse users by giving them multiple ways to do the same thing. From a maintainer's point of view, a proliferation of shortcuts lead to a maintenance nightmare.

Understandable, thanks anyway!