Strange/buggy exec ordering of `--bind transform-search()+best`

[Kache]

Checklist

• I have read through the manual page (man fzf)
• I have searched through the existing issues
• For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.73.1 (refs/tags/v0.73.1)

OS

• Linux (actually WSL)
• macOS
• Windows
• Etc.

Shell

• bash
• zsh
• fish

Problem / Steps to reproduce

I'm using fzf as a git log --graph viewer with preview (similar to gitk)

Am making a bind to jump to selected commit's first parent, using transform-search()+best

Expected alt-j (binding below) to be atomic and sequential execution of:

1. transform-search() /w command to return selected commit's first parent's SHA (alt-k)
2. best to jump both search and selection to that parent (alt-l)

Observing alt-j:
Hard to describe, it seems as ifbest partially executes first, then transform-search(), then remainder of best.

1. (optional) enter a query to apply a search filter and/or ctrl-j to change selection
2. records curr selection, let's call it "commit A"
3. jumps selection to first match of the current search/query, "commit B"
4. search is updated to highlight commit A's parent

The strange order of operations is very evident by applying 1. so selection differs from search filter, then repeating alt-j, causing search & selection to keep swapping places. The section will "chase" the previous search result, and the search result will "chase" the previous selection's parent. This is distinctly different from alt-k alt-l or alt-k ctrl-n, which behaves as expected.

Minimal repro:

git log --graph --all --oneline --decorate --color | \
    fzf --ansi --no-sort --reverse --raw \
        --bind alt-j:"transform-search(git lg-sha {} | xargs git parents-short | cut -f 1 -d ' ')+best" \
        --bind alt-k:"transform-search(git lg-sha {} | xargs git parents-short | cut -f 1 -d ' ')" \
        --bind alt-l:best

The git aliases being used:

  # takes a line from git log --graph output, only returns the SHA
  lg-sha = "!f() { \
    echo \"$1\" | grep -Eo '^\\W+ [0-9a-f]+' | grep -o '\\S*$'; \
  }; f"
  # parents of given ref, trimming to same length as input
  parents-short = "!f() { git log --pretty=%P -n 1 $1 | tr ' ' '\\n' | cut -c1-$(echo -n $1 | wc -c) | xargs; }; f"

Have also tried many variations, e.g. best+transform-search(), best+transform-search()+best(), transform-query(), first, down-match, etc

[junegunn]

It's because fzf's search runs asynchronously. When you do transform-search(new query)+best,

1. fzf starts a new asynchronous search for the "new query" in a separate thread
2. It moves the cursor to the "best" match

So it is not guaranteed that we have the final result for the "new query" when we run best action, which explains unpredictable results.

The only option we have is to bind result:best, so best is triggered whenever the result list is updated. You could use transform to conditionally trigger best. But I definitely understand this is not ergonomic and can be confusing.

We might need some kind of one-off callback mechanism to better deal with such requirements.

[junegunn]

Some ideas:

• Add an action to block the execution until the new result is available. Should not be used with a large input where search can take a while, but it should be okay for small lists. i.e. transform-search(new-query)+wait+best
• Add search-sync and transform-search-sync that synchronously wait for the result. i.e. transform-search-sync(new-query)+best
• Add an action that delays the subsequent actions until some event. i.e. transform-search(new-query)+when(result)+best
  • The UI is not blocked, so the user might perform actions that are not compatible with this chain of actions

[Kache]

Thanks for your thoughts on this. I was thinking similarly, though hit upon some questions:

• if transform-search() is async, then what is bg-transform-search()?
• does the async background search cancel and restart upon each keypress? seems in all cases (wait, sync, when()), the user should be able to cancel by changing the current query or selection, to retain responsiveness

[junegunn]

• if transform-search() is async, then what is bg-transform-search()?

The transform command runs synchronously. fzf starts asynchronous search using the output of the command.

# This makes fzf unresponsive for 3 seconds
fzf --bind 'space:trasnform-search:sleep 3; echo foo'

# This doesn't
fzf --bind 'space:bg-transform-search:sleep 3; echo foo'

• does the async background search cancel and restart upon each keypress?

Yes.

[junegunn]

If you have a chance, please test #4842.