ctrl+r no longer pulling from shared history until a command is run succesfully

[ohshazbot]

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.55.0 (brew)

OS

• Linux
• macOS
• Windows
• Etc.

Shell

• bash
• zsh
• fish

Problem / Steps to reproduce

This is very similar to #1649, except fc -rl 1 is behaving as expected

I have 2 terminals, I'm using zsh with setopt share_history. Outside of fzf, it works fine, if I go to a second terminal and type in a command, it is available on my first terminal after hitting a newline. However history is not being shared with fzf triggered via control+R until a command is run sucessfully.

• Have 2 terminals with shared history
• In terminal 2, input any command
• In terminal 1, control+r to enter fzf search and observe that the last command isn't present (nor is it if you search (assuming you haven't run the same command in the past)
• control + c out of fzf search
• input a blank new line and use control+r to observe that the input from terminal 2 still is not present
• control + c out of fzf search
• run a command, like fc -rl 1 or echo and use control+r to observe that now the input from terminal 2 is present

This feels like a regression, I feel it used to either get updated without having to invoke a command first (but I could be mistaken)

[LangLangBart]

I feel it used to either get updated without having to invoke a command first

Your assessment is correct. The issue came with #3823; the problem is with the associative history array, which doesn't update on a simple return as fc -rl 1 does, but only, as you pointed out, on some command.

fzf/shell/key-bindings.zsh

Lines 113 to 122 in 3c40b1b

	if zmodload -F zsh/parameter p:history 2>/dev/null && (( ${#commands[perl]} )); then
	selected="$(printf '%s\t%s\000' "${(kv)history[@]}" |
	perl -0 -ne 'if (!$seen{(/^\s*[0-9]+\**\t(.*)/s, $1)}++) { s/\n/\n\t/g; print; }' |
	FZF_DEFAULT_OPTS=$(__fzf_defaults "" "-n2..,.. --scheme=history --bind=ctrl-r:toggle-sort --wrap-sign '\t↳ ' --highlight-line ${FZF_CTRL_R_OPTS-} --query=${(qqq)LBUFFER} +m --read0") \
	FZF_DEFAULT_OPTS_FILE='' $(__fzfcmd))"
	else
	selected="$(fc -rl 1 | awk '{ cmd=$0; sub(/^[ \t]*[0-9]+\**[ \t]+/, "", cmd); if (!seen[cmd]++) print $0 }' |
	FZF_DEFAULT_OPTS=$(__fzf_defaults "" "-n2..,.. --scheme=history --bind=ctrl-r:toggle-sort --wrap-sign '\t↳ ' --highlight-line ${FZF_CTRL_R_OPTS-} --query=${(qqq)LBUFFER} +m") \
	FZF_DEFAULT_OPTS_FILE='' $(__fzfcmd))"
	fi

Workaround A: Modifies the sourcing by disabling the perl part, which also disables multiline command display.

source <(fzf --zsh | sed '/zmodload/s/perl/perl_off/')

Workaround B: Prepend fc -RI before ${(kv)history[@]} is called.

source <(fzf --zsh | sed '/history\[@\]/s/^/fc -RI; /')

---

It is unfortunate that zsh behaves differently between $history and fc -rl 1, and hopefully, this is just a bug in zsh.

In the meantime, you could share your enabled options by running the command below.

unsetopt KSH_OPTION_PRINT
print -r -- $(setopt)

And verify if the proposed workarounds give you back your previous experience. Enabling tracing for the fzf-history-widget lets you see what it does. No need to share the output.

# Verbose execution trace prompt (default: '+%N:%i> ')
PS4=$'\n%B%F{0}+ %D{%T:%3.} %2N:%I%f%b '
typeset -fT fzf-history-widget
# press ctrl-r