[BUG?] `reload` resets selections

[NightMachinery]

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

Info

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

Problem / Steps to reproduce

I use change:reload to update the inputs with newly arrived candidates. It works great, except that the reload clears the previous selections (i.e., it unmarks everything). The expected (to me) behavior is to keep the selected items, even if they are NOT present in the new input.

[junegunn]

Actually, that's the intended behavior and we have a test case for it.

https://github.com/junegunn/fzf/commit/05b5f3f845a88e9b034f3302bb50672fc5b7f8c7

I didn't like keeping the previous selections because once they're gone from the list, there's no direct way to un-select them or to see which ones are currently selected.

What is your actual use case?

[NightMachinery]

@junegunn

What is your actual use case?

I am trying to integrate my fzf functions with GUI programs; For example, I have a clipboard manager implemented via fzf, and I want to see this fzf “popup” when I press CMD+V. I achieve this by assigning the hotkey CMD+v to a (half-transparent) terminal window that is running the fzf program in a loop. This loop is basically running the fzf function that displays the current database of clipboard history, then hides the terminal window upon user selection, and pastes the results.

The problem is that it’s hard to know when the terminal window has gotten focus, so the fzf function is called immediately after one “session” finishes and the window is hidden. This results in the fzf input being stale.

Refreshing the input periodically is not a good solution as it might do the reload in the middle of a “session.”

I currently wait for the user’s first typed char to start fzf, but this is not ideal as I can’t see the candidates before typing that single char.

once they're gone from the list, there's no direct way to un-select them or to see which ones are currently selected.

Can’t we just keep any candidate that has been selected in the list forever? In my use case, the new input only adds new candidates, and so mapping could also be done, but the complexity doesn’t seem necessary.

[pyglot]

First: Thank you so much for fzf! It's really amazingly great!

I have a use-case where I am using fzf -m.

The use-case is to select multiple files and/or directories and yank them back to the command-line. I have set key bindings Ctrl+F and Ctrl+D to use reload to swap between filters for Files only or Directories only, but the selection is lost when running reload.

Here's a bash oneliner that shows the use of fzf in my use-case:

fdfind --color always | fzf --ansi --prompt '>' -m --header 'Select ^O/^P, File/Dir ^F/^D' \
 --bind 'ctrl-d:reload(fdfind --color always -t d)' --bind 'ctrl-f:reload(fdfind --color always -t f)' \
 --bind ctrl-o:select-all --bind ctrl-p:deselect-all

Some quick thoughts from me are:

• If the default behavior of reload was modified to keep the active selection, it could be possible to achieve the current behavior by combining deselect-all+reload.
• Expected behavior for a reload if it keeps the selection:
  • Reloading identical input items should not result in duplicate entries. (It is currently not the default behavior to remove duplicates, and not sure if there's a plan to allow it.)
  • The old selection should still be part of the list, visible and deselectable.
• I expect that these 'expectations' have some non-trivial consequences so it's maybe not so easy to provide the functionality without impacting performance.

[FilipeBento]

This would be amazing if implemented. Keeping my selection between different reloads would help greatly! I also understand it might not be easy to implement, though.