Feature: Set selected entries

[ggVGc]

It would be useful to be able to pass a list of strings that should be selected when launching fzf.
And, related, to pass a string on which the cursor should start. I am currently building https://github.com/ggVGc/fzf_browser and with these options the UI could behave much nicer.

[junegunn]

I also thought about those stuff, but I felt that maybe I was trying to squeeze too much out of fzf, beyond what it's supposed to do, unnecessarily making it more complex.

pass a list of strings that should be selected

It's doable. But I thought it can be very confusing if one of the "pre-selected" items is not listed on the initial page.

to pass a string on which the cursor should start

It's not as trivial as it seems since fzf works asynchronously. And I suppose you'll end up even wanting to preserve the scrolling offset of the window as well (well, I did). Maybe you could take advantage of execute action somehow in some cases.

I'm not going to rush into a decision, rather I'll leave this issue open and see how the idea develops.

[ggVGc]

Yeah, I understand there are some implementation design concerns with both of these, but I'm not sure it would be making "fzf unnecessarily too complex". I think it's more an ideological concern than a technical one(which is fine, fzf is your creation and should follow your ideas).
It's a great tool by itself, but even with current configuration options, also shines as a UI for other more complex applications. Writing fzf_browser around fzf was great, but as I mentioned would be even better with these two additions.
But maybe it's me thinking about fzf in a different light than you. In my opinion "bloat" is when you add things to your software that could as well have been implemented outside of it, or in an alternative way. When it comes to these two options, I don't see a way to work around it really.
So, if fzf wants to be a powerful building block within larger applications, I do think things like these options have a place.
Regarding implementation concerns I think it's not a big issue if pre-selected entries are off screen, since this can already happen during normal usage

And regarding the cursor position, I think a simple enough and intuitive implementation is:

• While loading, if the passed string(upon which the cursor should be) is not in the list, then just stay at top. When it shows up, move the cursor to it.
• If the user has moved the cursor at all, or entered any text, cancel(i.e don't put the cursor on the selected string, even if it shows up)

All these two things add is the ability to restore state upon re-launching fzf, not really introducing any new behaviour as far as I see. The main use case in my opinion is that the user has already built the state previously, so it shouldn't be surprising.

[junegunn]

Well, I said "more complex" not "too complex", so there's difference in nuance :)

So, if fzf wants to be a powerful building block within larger applications

Yeah, that's the point I'm not sure about. I'm also not sure if there's a strong demand to use fzf for such purposes. You know, I can't be super motivated to spend my time to implement and maintain esoteric features that only a handful of users will ever use. A broad feature set can intimidate most average users who only need small subsets of it and it usually makes the project less flexible to future changes (if we want to keep backward compatibility).

And regarding the cursor position, I think a simple enough and intuitive implementation is:

I personally don't like the suggestions. It's very annoying and confusing for me when my user interface is interfered by some unknown force asynchronously. I would rather block the interface until the item appears.

What I meant by scroll offset is that, if the list spans multiple pages, the item can appear on any position on the screen depending on how much you scrolled the list. So that's another missing piece of information when restoring the session.

[ggVGc]

Thanks for a good discussion, and I respect your decision :)
For what it's worth, I have since been using my fzf_browser tool daily and have not been hindered by the lack of this feature.

[haakonstorm]

This feature would enable a lot of new use cases.
fzf is an awesome selection and filter tool.

λ echo "A \n B \n C" | fzf --multi

>[ ] A     
  [ ] B     
  [ ] C

Selection tool is even more useful when it can come preselected.
A super useful application of this feature would be when a ML shell script
feeds back the results of its inference, but in the form of the complete set
of input, but the validated items now come pre-selected. Makes pipelineing
so much easier :)
Even the most basic implementation would be game changing:

λ echo "A \n B \n C" | fzf --multi --preselected="A"
[X] A     
[ ] B     
[ ] C

Variants:

external validator:
echo "A \n B \n C" | fzf --multi --preselector:'~/bin/true_if_preselected.zsh'

echo "Markdown Checkbox variant: \n
- [x] A \n
- [ ] B \n
- [ ] C \n" | fzf --multi --preselect-style=md

list of file paths to preselect from external file:
find . --max-depth=1 -name="foo" | fzf --multi > preselected.txt
find . --max-depth=1 -name="foo" | fzf --multi --preselected='preselected.txt'

👍

[junegunn]

It's not the kind of problem fzf was designed to solve. There are many tools more suitable for the use case such as smenu.

[Naheel-Azawy]

Hello, I know this is a bit old but I guess it's really important.
So, I wrote a little file manager using fzf https://github.com/Naheel-Azawy/fmz.
The problem is, imagine being in a directory with tons of files and directories. You open something and the pointer goes back to the first element. It gets so annoying really quick. I tried some hacks but that was nasty.
I believe adding it wouldn't be much of a bloat. Also, smenu is no where close to what we have in fzf.

I haven't gone over the code of fzf yet but I can imagine it would be few lines of code. Here's my proposal; as @haakonstorm mentioned, we can have the --preselector option. I believe this is enough and no need for the --preselected option.

When fzf starts, it reads the "preselector" file. The first line is the item pointed to. The rest of the lines are the marked items. When fzf exits, it updates the file based on the last state. For example, if we have this state in fzf:

>   < 6/6 (2)
  ~/Tmp/deadbeef: /dev/sda4 (17.9G/157.1G)
  coreutils
 >fzf
  20160515_120002.jpg
 *AD620-instamp.pdf
 *Linux- Rob Landley.mp4
  main.go

Then the preselector file content would be:

fzf
AD620-instamp.pdf
Linux- Rob Landley.mp4

[mikeslattery]

@junegunn it would be nice if there were a "start" or "onload" event.

Then users could implement things like this on their own, through the use of actions on startup.

[nkh]

I use fzf in 16 different commands here https://github.com/nkh/ftl, and I already have this use case for --pre-selection:

I use fzf to select multiple elements, some time later I want to deselect some elements and select new elements, all while having the possibility to fuzzy search the elements.

[tlamadon]

fzf is absolutely amazing! I would think that such feature could be a nice addition, but I also respect that the main developers on the project have particular preferences!

Looking at skim (a rust fzf), it seems that it supports such pre-selection with the --pre-select option. That might be a better option than smenu for some of the use cases I see here.

[Naheel-Azawy]

@tlamadon skim is nice as well. I tried messing around with it before.
For the --pre-select option in skim, it can only mark items but not set the pointer.
skim also lacks some options like --pointer, --info, etc. These can be added of course over time but development doesn't appear to be that active there.

[Delapouite]

it would be nice if there were a "start" or "onload" event.

A start event (useful under certain conditions) has been implemented recently : 168829b

[Naheel-Azawy]

Thanks @Delapouite, that looks promising.
I was thinking of how to move the pointer to a specific element.
A hacky way can be to find the index of the required element and then call up/down multiple times. But imagine selecting the 1000th element, that would be --bind 'start:up+up+ ... +up' a thousand times. Is there any nicer approach?