Feature request: add special event "start" for --bind

[denisidoro]

• Category
  • [x] fzf binary
  • [x] Key bindings
• Shell
  • [ ] bash
  • [ ] zsh
  • [ ] fish

Eg, I would like to have the second item highlighted on startup.

It would be nice to call fzf as in:

echo -e 'abc\ndef' | fzf --bind 'start:down'

For reference, this is the tool I'm developing. When going up one dir, I would like to highlight the last visited node.

[vovcacik]

Also useful to invert selection and only deselect some items manually.

[bew]

Also useful to invert selection and only deselect some items manually.

This would be my use case as well, I'd like to do start:select-all and allow user to deselect single entries or ranges (by making a search and toggle all matches). To be used in a pipeline like fd | fzf ... | entr ... to selectively watch a number of files, and execute a command on change.

@junegunn do you think it's hard to implement? If not too hard I might try to impl it

[junegunn]

Implementing it is trivial, I have a working copy locally, but I had some concerns.

fzf consumes the input asynchronously, so triggering the event immediately is probably not what you want.

# The whole list appears after 1.5 seconds
(sleep 0.5; seq 10; sleep 1; seq 10) | fzf

# Even without sleep, there is no guarantee that all data is available when fzf starts
any-command | fzf

So should we trigger start event upfront, or should we wait until the stream is complete? We could leave it up to the users and tell them to use --sync option. This is probably the easiest option for us, but I'm afraid many will misuse it.

[bew]

Good point. I'd be on the side of telling users the start event is best used with --sync for reliable actions on all inputs like select-all.

What's the behavior for the following cases without sync?

1. slow-seq 10 | fzf --bind start:down, does the selection follow the entry it was on on start? Or does it STAY on the 2nd one?
2. slow-seq 10 | fzf --bind start:select-all, what will be selected? When will they be selected?

For (2), do you think it would be possible to (maybe with another event or something) have all the entries asynchronously gathered, be selected? (this will probably not be as trivial)

[junegunn]

They are "actions", not "hooks". down action is triggered when you hit the down arrow key, and you don't expect your arrow key to do more than moving your cursor once. (I also have to mention that fzf starts with an empty input list, so down action on start without --sync will not do anything.)select-all is an action that "selects all matches" (for the current query). The items that have yet to come are not necessarily the matches for the current query, which may or may not be empty, which is not necessarily the same as the initial --query because the user can always change it, at the current moment, it doesn't make sense to select them. It contradicts the common expectation.

For (2), do you think it would be possible to (maybe with another event or something) have all the entries asynchronously gathered, be selected?

This particular use case is probably better addressed by a separate dedicated option, but it's a very niche use case, so I'd rather not add it, which may not work well with the existing options (such as --multi LIMIT). start event with --sync should suffice.

[bew]

I see, I understand. Then telling people to use --sync seems the simplest.

Did you have an example in mind when saying some might misuse it? As far as I understood, it can't give partially working behavior since there is no entries at start.

Or were you thinking about misuse where people use it without sync but it doesn't do anything useful, it doesn't work and they don't know why? I don't really think that's a case to handle.. They will test, then read the docs again (hopefully), then add sync if relevant to them.

[junegunn]

people use it without sync but it doesn't do anything useful, it doesn't work and they don't know why?

Exactly.

They will test, then read the docs again (hopefully)

Yes, hopefully :)