fzf: fzf causes splash when press ^R
- I have read through the manual page (
man fzf) - I have the latest version of fzf
- I have searched through the existing issues
Info
- OS
- Linux - Arch linux latest
- Mac OS X
- Windows
- Etc.
- Shell
- bash
- zsh
- fish
Problem / Steps to reproduce
I have below code:
# CTRL-R - Paste the selected command from history into the command line
fzf-history-widget() {
local selected num
setopt localoptions noglobsubst noposixbuiltins pipefail no_aliases 2> /dev/null
selected=( $(fc -rl 1 |
FZF_DEFAULT_OPTS="--height ${FZF_TMUX_HEIGHT:-40%} $FZF_DEFAULT_OPTS -n2..,.. --tiebreak=index --bind=ctrl-r:toggle-sort $FZF_CTRL_R_OPTS --query=${(qqq)LBUFFER} +m" $(__fzfcmd)) )
local ret=$?
if [ -n "$selected" ]; then
num=$selected[1]
if [ -n "$num" ]; then
zle vi-fetch-history -n $num
fi
fi
zle reset-prompt
return $ret
}
zle -N fzf-history-widget
bindkey '^R' fzf-history-widget
Notice the issue:
fc -rl 1 |
FZF_DEFAULT_OPTS="--height ${FZF_TMUX_HEIGHT:-40%} $FZF_DEFAULT_OPTS -n2..,.. --tiebreak=index --bind=ctrl-r:toggle-sort $FZF_CTRL_R_OPTS --query=${(qqq)LBUFFER} +m" $(__fzfcmd)
If I use fc as above, then fzf draw okay (meaning it will do only one draw).
If I use as below (need to get result from the fc command):
selected=( $(fc -rl 1 |
FZF_DEFAULT_OPTS="--height ${FZF_TMUX_HEIGHT:-40%} $FZF_DEFAULT_OPTS -n2..,.. --tiebreak=index --bind=ctrl-r:toggle-sort $FZF_CTRL_R_OPTS --query=${(qqq)LBUFFER} +m" $(__fzfcmd)) )
Then the prompt somehow give a double re-draw, causing quick splash/flick/flash.
So I don’t know what is the cause of this behavior, why putting them into a subshell causing the issue? or this is from fc command itself?
I tried to use fzy for test and fzy does not causing splash that is in subshell:
selected=$(fc -rl 1 | fzy)
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 26 (4 by maintainers)
I rename old
zsh_historytozsh_history,bakand start using new one for history, same all configs, no issue so far.So the only difference between old and new history file is the old one got corrupted in the past and I had recover it (don’t remember the command) successfully but I can guess it still cause this issue later.
That is not very helpful because it’s a trace when fzf runs without a problem.
Here is how to use strace with
fzfThis is just a theory, I’m not expecting a line in history to break
fzf, but I’m stumped on why do you get these problems.stracewill most likely help us to find the problem.I tried a minimal env and give it 50k zsh history to test and report back.