[FEATURE] Dynamic evaluation for change-prompt action

[levouh]

• 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

Background

Lets say I have a script that runs similar to something like rofi with custom modi, where I can do something like fzf ... --bind 'ctrl-l:reload(menu -n),ctrl-h:reload(menu -p)', where menu is just a wrapper to track state and reload what is provided for fzf to filter on. I can start with a list of:

> 
egg
cheese
milk

then press ctrl-l, and I would be shown the next list of:

>
cat
dog
bird

which is amazing, and fzf is a wonderful tool to do this with. However, things become a bit more difficult when two of these lists are similar, but not the same, and hence I'm not really sure what I'm looking at.

Request

Update the change-prompt action, or perhaps add a different one like change-prompt-eval, which will evaluate the command inside of the action call, and use that as the prompt for fzf. Then, my above script would change to call fzf like fzf ... --bind 'ctrl-l:reload(menu -n)+change-prompt-eval(echo $MENU_PROMPT),ctrl-h:reload(menu -p)+change-prompt-eval(echo $MENU_PROMPT). The value of the environment variable MENU_PROMPT would be updated during the previous reload call to menu -n or menu -p.

Excuse me if I am missing functionality here, but as far as I understand it, I could do something like fzf ... --bind 'ctrl-l:reload(find . -type f):change-prompt(Files> ),ctrl-h:reload(find . -type d):change-prompt(Directories> )', given that there are only a few modes with their own distinct bindings. However, the set of modes in this script is theoretically infinite, so just like I can dynamically generate the next state, I'd like to be able to dynamically generate the next prompt as well.

The end result would leave us with something like:

Groceries> 
egg
cheese
milk

and

Pets>
cat
dog
bird

and would allow me to clearly discern that I have a dog as a pet, not milk and cheese.

[junegunn]

The value of the environment variable MENU_PROMPT would be updated during the previous reload call

That won't work. Once the child process terminates, the environment variables set in the process are lost.

sh -c 'FOO=1'
echo $FOO
  # Nope

Have you considered using --header-lines option? It's a simple and effective way to convey the context.

[levouh]

I wasn't aware of --header-lines, and you're right, it's effectively the exact same thing. Thanks for the input!

[githorse]

I'm looking for the same feature -- dynamic prompt evaluation. Specifically, I'm trying to emulate something like the "search engine" feature in Firefox and Chrome so that if the user types a specific trigger, it changes the prompt to indicate a particular "search engine" is active. So maybe I type files: to search files:

and then dirs: to search directories:

--header-lines is a great option, but doesn't quite re-create the effect I'm looking for here. I realize the environmental variable thing won't work, but could this be bound to an executable in the same way as a reload (or other) events?

$ fzf --bind 'change:change-prompt(format_prompt {q})`

(I realize this won't quite work in my case since I'll have to also delete the files: from the query string; I have a separate issue open for that.)