FZF should update preview on the new item selection immediately

[FallenGameR]

• [x] I have read through the manual page (man fzf)
• [x] I have the latest version of fzf (tested that on 0.35.1 last available through choco on windows)
• [x] I have searched through the existing issues

Info

• OS
  • [x] Windows
• Shell
  • [x] pwsh

Problem / Steps to reproduce

• --preview is running a script that can finish fast or slow depending on the selected item (e.g. fzf selects folders and preview shows the total folder size)
• you select a slow item, preview starts rendering
• you change selection to a fast item, but you still see in the preview that fzf waits for the the render of the slow item to finish

Fzf should not wait for the preview render of the item that is not selected anymore. It should kill the uncompleted preview render and show preview for the currently selected item.

[junegunn]

• you change selection to a fast item, but you still see in the preview that fzf waits for the the render of the slow item to finish

Maybe this is an issue only on Windows? I don't have the problem on my MacBook.

# Move the cursor up, and you will see 0 before 10 seconds pass
(echo 10; echo 0) | fzf --preview 'sleep {}; echo {}'

There's a slight delay before fzf kills the running preview process but that's for a better user experience. If fzf immediately kills each preview process, you will end up seeing an empty preview window when you hold down the up or down key scrolling through the list.

# Simulating a preview program that takes 200ms to render the output
# - Hold down up or down key, and fzf can keep updating the preview window with new content
# - That's because fzf keeps the process running for `previewCancelWait` (500ms) and can get the output
# - If you remove the delay, fzf never gets any output and the preview window will be empty
fzf --preview 'sleep 0.2; cat {}'

[FallenGameR]

It doesn't seem like a Windows issue. I can repro the problem with the (echo 10; echo 0) | fzf --preview 'sleep {}; echo {}' on a Linux Mint in a bash terminal. When I switch several times back and forth between 0 and 10 the preview window lags behind the selection.

For the repro completeness here are my default fzf options that I have applied:

fallengamer@omen-mint:~$ echo $FZF_DEFAULT_OPTS
--layout=reverse --tabstop=4 --multi --bind alt-t:toggle-all --cycle --ansi --no-mouse --tiebreak='length,index' --color=bg:#0C0C0C --color=bg+:#0C0C0C --color=fg+:#F2F2F2 --color=hl+:#13A10E --color=pointer:#3A96DD --color=preview-bg:#0C0C0C --color=prompt:#CCCCCC

[junegunn]

lags behind the selection

For full 10 seconds?

[FallenGameR]

Yesterday when I tried it out on Mint it seemed to stuck in the 'loading' state for 10 seconds when the selection switched to 0. But today on the same Mint I can't repro that anymore - there is the less than a second previewCancelWait delay but then the preview changes to reflect the selection. Will try out more to get the repro.

[FallenGameR]

For now I can show repro only for Windows: https://1drv.ms/v/s!AofupOwTJgR3wbhtE_kwqXQa421v_A?e=YjFA87 My expectation is that the current selection should be reflected in the preview with <1 second delay. But as seen at the end of the video "0" is not printed out for about 10 seconds.

[omerxx]

Hey, experiencing the same on MacOS (M3 2024 if it matters). With a 0.7 delay the preview updates itself, 0.6 seems to be the threshold, below I'm seeing and old input.